Adobe Launch hasn’t been out long, but I’ve managed to break it a few times. Okay, maybe Launch wasn’t broken. I was just doing something wrong and didn’t realize it. Before you get your hands dirty, store this in the back of your head so you don’t experience the same headache I suffered. Before I begin, I’d like to throw in a quick shout-out to Jan Exner who is (and will be) posting a lot of good stuff about the nuts and bolts of the platform. I’m looking forward to learning how to use the API via his blog *hint hint*.
Let’s cut to the chase and dive into my mistakes so far.
8/2019 Update: Adobe has since improved this experience. The errors are much more specific and are clearer to the user.
In DTM, the code editor checked your code and wouldn’t let you save the script until errors were resolved. While the code editor will call out your error, it will still let you save it. The Adobe Launch custom code editor will only check your code on change. That means you can paste or type code into the editor and save it without triggering the code QA. While it’s nice to be able to save the code with errors (so we can fix it later), they will often go unnoticed until it’s time to build your library. That’s when you get that red dot and the message that says “Last build was not successful”.
Here’s the crazy part – there’s no indication of why the library build was unsuccessful in the publishing workflow. I assumed Launch was down for maintenance. After checking in the next day, the library still wouldn’t build! I deleted it and recreated it. I removed some rules, added others. I tried reverting changes. I tried everything. After asking around, I was pointed to the Library screen where there’s an error message tucked off to the side of the screen. AHA!
If you listen carefully, you can already hear client care screaming. Let’s be real, though. There’s plenty of time to apply more appropriate treatment for these messages. I simply didn’t know where to look.
Gotcha 2: Libraries don’t default to an environment
8/2019 Update: The gtag extension by Philip Lawrence is absolutely brilliant and solves this issue.
So I’m trying to push out my latest round of changes – my third iteration of the day. It happens, I’m working with 4 vendors trying to slap their pixels on my marketing page. I click the button to create a library, name it, add the changes, and click save. Then I realize…
Forgot to specify the environment. Now I can’t build it. Every. Single. Time. Maybe this is less of a “gotcha” and more of a waste of time (that’s what a “gotcha” is, right?). I’d say 75% of the time I save the library before specifying an environment… usually because I’m in a rush. That said, it’s a good feature to NOT default to an environment so the place you push your new tags is more intentional. I recommend you use this little acronym in the hope that it might help you remember. Make sure you ACE it. Always Check the Environment.
Yes it’s lame, but if it works… let me know because I still manage to screw it up.
Update from Corey Spencer @ Adobe in the comments:
Last week we released a feature we call “Active Library”. If you log into Launch you’ll see that when you start to edit a rule, element or extension you can select the library you want to publish this change to, and build right from that page. It should save you a ton of time.
Gotcha 3: Google Analytics extension only supports 1 GA implementation
You’re using an Adobe tool – why do you still run 3 different instances of Google Analytics on your site? Unbelievable! Yes, this is still relatively common. If you’re one of these people who run multiple instances of Google Analytics on your site, keep in mind that the Adobe Launch’s Google Analytics extension does not currently support multiple instances of Google Analytics (and no, you can’t add the same extension twice).
THAT SAID, you can still implement Google Analytics via the Custom Code module and deploy it outside of Adobe Launch’s convenient template. If I was a betting man, I’d wager multiple instances of Google Analytics accounts is probably on the roadmap.
These aren’t bad “gotchas”. This is actually pretty darn benign. “Problems” like choosing the environment will become more mechanical with practice. Additionally, once you figure out where build errors are, you’ll never forget it. I still haven’t yet explored all of the nooks and crannies of the tool and I’m sure there are some of you out there who have discovered some really good ones. In the meantime, check out the new Adobe Launch Cheat Sheet so you don’t find yourself trying to use stuff that used to work in Adobe DTM.
Gotcha 1. You’re right, we need to make the error handling more evident. We’ll work on that.
Gotcha 2. Last week we released a feature we call “Active Library”. If you log into Launch you’ll see that when you start to edit a rule, element or extension you can select the library you want to publish this change to, and build right from that page. It should save you a ton of time.
Gotcha 3. We thought a lot about this issue. Launch allows a user to install one instance of an extension. This is on purpose. Originally we were going to allow for multiple installs of an extension. Doing this would require EVERY extension developer to deal with the complexity of multiple installs (upgrading, managing, developing) which seemed like a high burden since 95% of extensions will only allow/require a single install. Instead, we opted for a single install per extension, BUT an extension developer could build an extension which allows for multiple instances within the extension. In other words, this is Adobe’s version of the GA extension, but in the near future someone else could build an extension which allows for one extension install, but multiple instances of GA managed within the extension. I hope that makes sense.
Thanks, Corey! The fact that I only found 3 “gotchas” is completely astounding. When I worked with Satellite in its early days, I ran into something every day. You and the Launch team are doing some great work. I’ll update the post with the new information.
The extension explanation makes some sense. Certainly I agree that adding accommodations that only 5% will use shouldn’t affect the other 95%. The part I need to digest is the scale of what can be done on Launch via extensions, I’m not sure how outlandish I can get with it. Perhaps it should be thought of through the lens of “What can I NOT do?”
Thank you for Gotcha 1: Library build unsuccessful error. Found this article via search. I’m guessing there are others in this boat as well. It could be much simpler.
Hello Great work to help us do less errors.
What are the dataLayer specs we need to pass to do a GA enhanced ecommerce please but using Launch ? (yes use Launch + GA). For instance an add to cart please