{"id":544,"date":"2018-10-29T20:23:00","date_gmt":"2018-10-29T20:23:00","guid":{"rendered":"https:\/\/www.digitaldatatactics.com\/?p=544"},"modified":"2020-09-17T21:15:19","modified_gmt":"2020-09-17T21:15:19","slug":"dtm-to-launch-migration-series-2-a-golden-opportunity","status":"publish","type":"post","link":"https:\/\/www.digitaldatatactics.com\/index.php\/2018\/10\/29\/dtm-to-launch-migration-series-2-a-golden-opportunity\/","title":{"rendered":"DTM-to-Launch Migration Series #2: A Golden Opportunity"},"content":{"rendered":"\n<div class=\"wp-block-image\"><figure class=\"alignright size-thumbnail is-resized\"><img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/www.digitaldatatactics.com\/wp\/wp-content\/uploads\/2020\/09\/33sticks_logo-150x150.png\" alt=\"33 Sticks Logo- Orange Circle with 3|3 in it\" class=\"wp-image-538\" width=\"75\" height=\"75\" srcset=\"https:\/\/www.digitaldatatactics.com\/wp\/wp-content\/uploads\/2020\/09\/33sticks_logo-150x150.png 150w, https:\/\/www.digitaldatatactics.com\/wp\/wp-content\/uploads\/2020\/09\/33sticks_logo-300x300.png 300w, https:\/\/www.digitaldatatactics.com\/wp\/wp-content\/uploads\/2020\/09\/33sticks_logo.png 441w\" sizes=\"(max-width: 75px) 100vw, 75px\" \/><\/figure><\/div>\n\n\n\n<p>(Cross-posted from the 33 Sticks blog)<\/p>\n\n\n\n<p>Aside from all of the things that Launch handles better than DTM did (which I discussed a bit&nbsp;<a href=\"https:\/\/33sticks.com\/dtm-launch-migration-series-1-options-considerations\/\">in my previous post in the series<\/a>), a move to Launch provides an opportunity to clean up and optimize your implementation (to the point that even if you weren\u2019t moving to Launch, you could still do this clean up within DTM). You can save yourself from headaches and regret down the line if you take the time now to define some standards, adopt some best practices, or apply some \u201clessons learned\u201d from your DTM implementation.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"properties\">Redo Your Property Structure<\/h2>\n\n\n\n<p>Many companies set up their DTM properties based on a certain understanding of how properties should be used, and realized a bit too late that a different set up might work better.<br>A&nbsp;<a href=\"https:\/\/www.digitaldatatactics.com\/index.php\/2016\/07\/06\/should-i-have-one-dtm-property-or-many\/\" target=\"_blank\" rel=\"noreferrer noopener\">previous post of mine<\/a>&nbsp;on this topic is still applicable in Launch: your properties should not be based on Report Suites or domains, but rather, on the three following questions:<\/p>\n\n\n\n<ul><li>How similar are the implementations between your sites (do they use the same data layer, for instance? Would the rules be triggered by the same conditions?)<\/li><li>How similar are the publication timelines (if you publish a change for Site A, would it also apply to Site B at that time?)<\/li><li>Will the DTM\/Launch implementation be maintained\/updated by the same folks? (Properties are a good way to control user access.)<\/li><\/ul>\n\n\n\n<p>Keep in mind Launch has an API for configuration, so if you have 15 properties and want to make a change to all of them at once, you now can (though that API is not yet super documented\/supported, so it\u2019s a bit of a wild west so far). In general, I\u2019ve seen folks using Launch as an opportunity to move to fewer properties.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"standards\">Define Standards and Best Practices<\/h2>\n\n\n\n<p>Now is a great time to take lessons learned from DTM and define the standards your company will follow within Launch. Some things are arbitrary- it doesn\u2019t really matter if I name the rule \u201cProduct Details Page View\u201d or \u201cpage: product details\u201d, but&nbsp;if we are consistent from the start, it can save us a lot of head ache and cleanup down the road.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"conditions\">Tags With the Same Condition(s)\/Scope Should Share the Same Rule<\/h3>\n\n\n\n<p>To keep your library light, and your implementation scalable and maintainable, I highly recommend basing your rules on their scope\/condition, rather than the tags they contain. For instance, a single rule named \u201cCheckout: Order Confirmation\u201d is better than 10 different rules that fire on Order Confirmation- \u201cDoubleclick Order Confirmation\u201d and \u201cGoogle Conversion Tags\u201d, etc.<br>I\u2019ve&nbsp;<a href=\"http:\/\/www.digitaldatatactics.com\/index.php\/2016\/07\/06\/what-the-dtm-top-down-approach-means-for-your-page-performance\/\" target=\"_blank\" rel=\"noreferrer noopener\">written previously about why this matters<\/a>\u2013 it can have a surprising affect on page performance (not to mention it cane make your TMS impossible to navigate\/maintain), and that still applies in Launch.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"cleanUp\">Delete redundant and unused stuff<\/h3>\n\n\n\n<p>Run an audit of your DTM property. Do you have redundant or unused Data Elements? Empty (or permanently commented-out) rules or Third Party Tags? Inactive rules or data elements that aren\u2019t likely to ever be used again? Often folks are afraid to delete things within DTM, but this is a great chance to delete anything that isn\u2019t still useful.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"naming\">Institute a Naming Schema<\/h3>\n\n\n\n<p>This is your chance to have a nice, clean naming standard in your TMS. Consider all the following things you can name in Launch:<\/p>\n\n\n\n<ul><li><strong>Data Elements<\/strong>: I try to keep to the same [category]:[details], though since Launch doesn\u2019t show the DE type from the DE list like DTM does, I also like to include the type: \u201csearch: term: QP\u201d (QP for Query Parameter) or \u201ccheckout: order total:DL\u201d (DL for Data Layer). I also prefer keeping everything for Data Elements lowercase so I don\u2019t have to worry\/remember how I capitalized things.<\/li><li><strong>Rules<\/strong>: In DTM I liked to do something like \u201c[category]:[scope\/condition]\u201d (eg \u201cSearch: Results\u201d, \u201cCatalog: Product Details\u201d, \u201cCheckout: Cart View\u201d.) In Launch, because DCRs, EBRs and PLRs now share the same interface, I like to take it a step further and include the rule type at the front: \u201cPage: Search: Results\u201d or \u201cClick: Search: Filter\u201d. If you have a lot of rules potentially firing into the same beacon, then I\u2019d also include info about the order (eg, \u201cPage: Global: All Pages #100\u201d and \u201cPage: Home #25\u201d so you know that the #100 one would fire AFTER the #25 one on the home page.) I\u2019ve also found it helpful to call out the rules which actually fire my analytics BEACON as opposed to rules that run&nbsp;higher in the order and only set variables (eg:&nbsp;\u201cPage: Global: All Pages (s.t) #100\u201d). Then within Rules, there are more naming considerations than there had been in DTM:<ul><li><strong>Events:<\/strong>&nbsp;Should be descriptive, and it may be worth including the load order (so \u201cPage Top- #100\u201d or \u201cDirect Call: Add to Cart #50\u201d might do the trick.)<\/li><li><strong>Conditions\/Exceptions<\/strong>: Conditions and Exceptions particularly should have some sort of custom naming (instead of a condition \u201cCore \u2013 Value Comparison\u201d, I might name it \u201cpageName DE=\u2019search results\u2019\u201d).<\/li><li><strong>Actions<\/strong>: I\u2019ve been leaving some with the default (eg, \u201cAdobe Analytics \u2013 Set Variables\u201d, though depending on how complicated my implementation is, I might want to change that to \u201cAnalytics- Content Identification variables\u201d). Any Core\/Code actions should have a descriptive name (\u201cYahoo pixel- expires 12\/19\/19\u201d or similar.)<\/li><\/ul><\/li><\/ul>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"dataLayer\">Fix Up Your Data Layer<\/h3>\n\n\n\n<p>This is perhaps a very ambitious task for most migrations, but if you\u2019re already taking the effort to audit your DTM implementation, now might be a good time to also look at your data layer- do you have data layer objects that aren\u2019t being used in DTM at all currently? (Be aware, of course, that data layers don\u2019t always exist solely for a TMS\u2019s sake- make sure no one else is using it either). Before you go creating a bunch of data elements, is there something you wish your data layer had that it currently doesn\u2019t? Or do you wish it were structured differently? Now might be a good chance to optimize it! Especially if you are rolling Launch out to one part of your site at a time, you may be able to work with devs to break up a Data Layer rollout into reasonable chunks. You may be surprised by how many devs are on board with fixing up the data layer, particularly if your current on is messy\/confusing.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"tags\">Move Third Party Tags to Asynchronous JS<\/h3>\n\n\n\n<p>This is one of the biggest areas for improvement I\u2019ve seen amongst my current and past clients- they\u2019ve potentially been using DTM for years and haven\u2019t always taken advantage of DTM\u2019s ability to improve page performance by moving third-party tags to asynchronous javascript.All tag managements systems have inherent weight- you are adding a JS library to your site. If you don\u2019t mitigate this weight by using the TMS to optimize your tags, your TMS may be having a net-negative affect on your site- a substantial one, in many cases.&nbsp;I\u2019ve&nbsp;<a href=\"http:\/\/www.digitaldatatactics.com\/index.php\/2016\/07\/06\/dtm-third-party\/\" target=\"_blank\" rel=\"noreferrer noopener\">written previously<\/a>&nbsp;about the approach I would recommend for third-party tags, but to emphasize the importance of this:&nbsp;<strong>I have seen the overall page load time improve by 15-30% by simply moving tags within DTM to async.<\/strong>&nbsp;Unless the vendor\u2019s code affects the user experience (chat, survey or optimization tools, for instance),&nbsp;<strong>there is no reason for most tags to be anything other than non-sequential JS<\/strong>.<\/p>\n\n\n\n<p>In Launch, you can take it a step further, and use extensions to further optimize your tags. For instance, if you use Facebook or Doubleclick, there are extensions in place that you can use to move those tags entirely out of custom code blocks. Or, if you are deploying a simple pixel tag and the vendor does not have an extension, you can use 33 Sticks\u2019&nbsp;<a href=\"https:\/\/www.adobeexchange.com\/experiencecloud.details.100152.html\" target=\"_blank\" rel=\"noreferrer noopener\">Pixel Loader extension<\/a>&nbsp;to easily change it from an html&nbsp;&nbsp;tag to asynchronous javascript.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"document\">Document Everything!<\/h3>\n\n\n\n<p>Moving to Launch also provides the ability to get solid, current documentation on your solution. Aside from auditing your solution (I\u2019ll take about that in a moment) so you know which rules are setting what or what is expected in the Data Layer on certain pages, I also recommend using this fresh start as a change to document and enforce your standards and best practices for TMS deployment. For instance, I\u2019ve helped clients create a confluence document that anyone at thier company who might be within Launch can access, detailing:<\/p>\n\n\n\n<ul><li><strong>Naming Strategy<\/strong>&nbsp;(see notes above)<\/li><li><strong>Third Party Tag<\/strong>&nbsp;deployment standards (which tags are \u201capproved\u201d by your org for use- as in, \u201cdo not use one TMS to deploy another TMS like GTM, not unless you hate your site loading quickly\u201d); deploying&nbsp;tags as asynchronous JS- see note above\u2026)<ul><li>I also recommend as part of the&nbsp;<strong>auditing\/documentation process<\/strong>&nbsp;getting a list of all your third party tags, documenting who at your org \u201cowns\u201d that tag, and setting \u201cexpiration\/renewal\u201d dates (\u201cJan Smith owns this floodlight tag, deployed 8-5-18; on 9-5-18 we will contact her to see if the tag is still valid or can be deleted\u201d).<\/li><\/ul><\/li><li><strong>Best Practices<\/strong>&nbsp;(don\u2019t check \u201capply handler directly to element\u201d without good reason, try to limit the number of Data Elements used in \u201cData Element Change\u201d rule triggers, etc.)<\/li><li><strong>Publication Flow<\/strong>&nbsp;(how is your org using libraries and environments? Who approves and who publishes? Will publishing happen with a specific cadence, like every other Wednesday? What is your QA\/validation process? Do you want to implement an \u201call changes must be reviewed by someone other than the person who made the change\u201d rule?)<\/li><\/ul>\n\n\n\n<p>I know this level of documentation can be daunting and seem like overkill, but your future staff\/employees will thank you for it, even if it\u2019s informal&nbsp;and\/or a work-in-progress.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"deployment\">Change Your Deployment Method (Adobe-Managed vs Self-Hosted)<\/h3>\n\n\n\n<p>DTM had a few deployment options:<\/p>\n\n\n\n<ul><li>An Adobe\/Akamai-hosted library (ie, your embed code starts with \u201c\/\/assets.adobedtm.com\u201d)<\/li><li>An FTP self-hosted library (DTM would push changes through FTP to a location on your own servers)<\/li><li>A downloaded self-hosting option (you would manually download after changes and put onto your servers).<\/li><\/ul>\n\n\n\n<p>Now may be an opportunity to change this- if you\u2019ve been doing the manual download option because of security concerns, now that the publishing flow in Launch is more flexible\/powerful, might you be able to simplify by moving to another option?<\/p>\n\n\n\n<p>Technically, all three of these options also exist in Launch, though the approach is slightly different. I\u2019ve documented&nbsp;<a href=\"https:\/\/33sticks.com\/how-to-self-host-a-launch-library\/\">in a separate post<\/a>&nbsp;how you can achieve each of the three methods in Launch- especially the download method, which may not be intuitive for users who had used the download option in DTM.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"libraries\">Update Your visitorID\/appMeasurement Libraries<\/h3>\n\n\n\n<p>A TMS upgrade is also a good chance to update to the most recent stable Adobe libraries (for instance, as of this moment, the&nbsp;<a href=\"https:\/\/marketing.adobe.com\/resources\/help\/en_US\/sc\/appmeasurement\/release\/c_release_notes_mjs.html\" target=\"_blank\" rel=\"noreferrer noopener\">most current Analytics library is 2.10<\/a>). Unless you are doing something very custom\/weird in your libraries (or are stuck in the dark ages on H code), updating should be a relatively easy process, and offers benefits like improved page performance.<\/p>\n\n\n\n<p>It may also make sense to examine your doPlugins function (if you are still using it): do you have functionality you can move out of doPlugins (eg, do you still really need getQueryParam when you can just use the DTM\/Launch interface?) (Also, word on the street is that some folks at Adobe may be releasing an extension to handle many of the common plugins, so that may provide some extra room for enhancement.)<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"adobeTools\">Update cross-Adobe Tool integrations<\/h3>\n\n\n\n<p>If you\u2019re not yet on&nbsp;<a href=\"https:\/\/marketing.adobe.com\/resources\/help\/en_US\/mcvid\/mcvid-overview.html\" target=\"_blank\" rel=\"noreferrer noopener\">the VisitorID service<\/a>, you really should be. Then once you are on that, now would be a good time to update your implementation for integrating analytics with other Adobe tools:<\/p>\n\n\n\n<ul><li>If you use Target, are you on at.js (and is it current)? Do you have Analytics 4 Target (A4T) set up?<\/li><li>If you use Audience Manager, have you transitioned to a server-side integration? Are you currently deploying your DIL at the bottom of your Analytics code in DTM, and might you be able to transition that to use the AAM extension?<\/li><\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">What\u2019s Next<\/h2>\n\n\n\n<p>By now, you should have a sense of what&nbsp;type of migration&nbsp;path you\u2019re going to take, and what aspects of your solution you may want to change or improve upon. The&nbsp;<a href=\"https:\/\/33sticks.com\/dtm-launch-migration-series-3-migration-process\/\">next post in the series<\/a>&nbsp;will walk you through the actual process and provide a rough framework for a project plan.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>(Cross-posted from the 33 Sticks blog) Aside from all of the things that Launch handles better than DTM did (which I discussed a bit&nbsp;in my previous post in the series), a move to Launch provides an opportunity to clean up and optimize your implementation (to the point that even if you weren\u2019t moving to Launch, &#8230; <a title=\"DTM-to-Launch Migration Series #2: A Golden Opportunity\" class=\"read-more\" href=\"https:\/\/www.digitaldatatactics.com\/index.php\/2018\/10\/29\/dtm-to-launch-migration-series-2-a-golden-opportunity\/\" aria-label=\"Read more about DTM-to-Launch Migration Series #2: A Golden Opportunity\">Read more<\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[23],"tags":[57,8,45,51,42],"_links":{"self":[{"href":"https:\/\/www.digitaldatatactics.com\/index.php\/wp-json\/wp\/v2\/posts\/544"}],"collection":[{"href":"https:\/\/www.digitaldatatactics.com\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.digitaldatatactics.com\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.digitaldatatactics.com\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.digitaldatatactics.com\/index.php\/wp-json\/wp\/v2\/comments?post=544"}],"version-history":[{"count":1,"href":"https:\/\/www.digitaldatatactics.com\/index.php\/wp-json\/wp\/v2\/posts\/544\/revisions"}],"predecessor-version":[{"id":545,"href":"https:\/\/www.digitaldatatactics.com\/index.php\/wp-json\/wp\/v2\/posts\/544\/revisions\/545"}],"wp:attachment":[{"href":"https:\/\/www.digitaldatatactics.com\/index.php\/wp-json\/wp\/v2\/media?parent=544"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.digitaldatatactics.com\/index.php\/wp-json\/wp\/v2\/categories?post=544"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.digitaldatatactics.com\/index.php\/wp-json\/wp\/v2\/tags?post=544"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}