Failure to Launch – 3 Adobe Launch Gotchas

By | 01/15/2018

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.

Gotcha 1: Your library isn’t building because of JavaScript errors.

Last Build Was Not Successful

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!

Build Error

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

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…

Saving New Libraries

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).

Adobe Launch Google Analytics

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.

Final Thoughts

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.

2 thoughts on “Failure to Launch – 3 Adobe Launch Gotchas

  1. Corey Spencer

    Hey Jim,

    Nice Post.

    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.

    Reply
    1. Jimalytics Post author

      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?”

      Reply

Leave a Reply

Your email address will not be published. Required fields are marked *