It’s common for a company in DTM to have multiple sites\/groups\/regions they want to deploy DTM on. One of the more important decisions you can make, early on, is whether to keep those different sites as separate properties, or keep them in a single DTM property. I know future iterations of the DTM tool will make up for some of the current issues we run up against when using multiple properties, but for now\u00a0my advice is to keep as few properties as possible- it’s so much easier to maintain.<\/p>\n
Note: Your properties in DTM are NOT related to your Adobe Analytics login companies or Report Suites- one property can go to many report suites (with custom logic in the s_code) or many properties can feed into the same report suite. So instead, you should\u00a0consider the following:<\/p>\n
Will the sites all have the same source for data, like a data layer, or CSS selectors? Do they use the same general analytics variable map (eg, “eVar15 is always search terms”)? Will they generally use the same third party tags? Do they all use Adobe Target or other DTM tools?<\/em><\/p>\n If your sites are similar and you want to keep separate properties, you can in theory set up one property and get it configured just right, then copy your rules and data elements over to all the other properties. But be warned: after rules are copied, if you need to update that rule, you must update all its copies too. To be honest, this can be beastly to maintain. I’ve seen it work, but only if folks use documentation to note what changes have happened where. Another big consideration are the tools for each site. Tools in DTM are generally intended to be deployed on ALL pages using that DTM property- meaning you can’t turn on Target or the Marketing Cloud service for just one portion of a property. For Adobe Analytics, you can suppress the tool on certain pages<\/a>, but in general, plan on Tools in DTM running on every page, without being able to suppress them for certain pages.<\/p>\n Will one site\u00a0go live with the Analytics tool sooner than another? Does another site have a lengthy QA process? \u00a0Would it be ok to publish changes in DTM that will push out to all sites at once?<\/em><\/p>\n If Site B will have their old Analytics implementation removed from their site and ready for DTM to take over in June, and Site B won’t be ready until August, then you’d need to plan things very carefully in DTM.\u00a0If the plan to transition to DTM really<\/em> varies between your sites, then you may want to keep separate properties, at least for now. Perhaps in the future you could merge them back together.<\/p>\n Will the person implementing\/administering DTM for one site be the same as for another site? Are you concerned about someone adding third party tags for site B having access to rules that could apply to site A?\u00a0<\/em><\/p>\n Within a company, you can use groups to restrict Users to certain properties. So you could say “Joe should only have access to Site B” if Site B is its own property.<\/p>\n Within a property, you can use groups to restrict Users to certain tools (for instance, you can give someone access to Third Party Tags but not to Adobe Analytics). You cannot, however, restrict certain rules- you can’t say “Joe can edit the homepage rule, but not purchase confirmation”.<\/p>\n On a side note, you can not restrict Admin access- if someone needs to make changes to tools, manage users, or view embed codes, that someone will have admin access for your whole company. So you can’t say “Joe should have access to the embed options for Site A but not Site B”.<\/p>\n If your sites are at all similar in their implementation, I think it’s worth it to try to make a single property work, but I definitely understand there are situations in which you must keep separate properties.\u00a0Hopefully this post will help you decide on the best possible arrangement for your company.<\/p>\n","protected":false},"excerpt":{"rendered":" It’s common for a company in DTM to have multiple sites\/groups\/regions they want to deploy DTM on. One of the more important decisions you can make, early on, is whether to keep those different sites as separate properties, or keep them in a single DTM property. I know future iterations of the DTM tool will … 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":[7,23,18],"tags":[],"_links":{"self":[{"href":"https:\/\/www.digitaldatatactics.com\/index.php\/wp-json\/wp\/v2\/posts\/222"}],"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=222"}],"version-history":[{"count":1,"href":"https:\/\/www.digitaldatatactics.com\/index.php\/wp-json\/wp\/v2\/posts\/222\/revisions"}],"predecessor-version":[{"id":223,"href":"https:\/\/www.digitaldatatactics.com\/index.php\/wp-json\/wp\/v2\/posts\/222\/revisions\/223"}],"wp:attachment":[{"href":"https:\/\/www.digitaldatatactics.com\/index.php\/wp-json\/wp\/v2\/media?parent=222"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.digitaldatatactics.com\/index.php\/wp-json\/wp\/v2\/categories?post=222"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.digitaldatatactics.com\/index.php\/wp-json\/wp\/v2\/tags?post=222"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
\nImagine you want to add a new variable to your Search Results page, and you have 6 properties that have similar Search Results rules- you’d need to make that change in all 6 properties, and approve and publish in 6 places.
\nIf, however, of your 6 sites, only 3 have a search results page, and all of them are pulling the search term out of a different query string parameter- then you’re going to be maintaining 6 separate rules anyways, and there is no benefit to keeping one property.<\/p>\nHow similar are the publication timelines?<\/h3>\n
Who will be doing the DTM work for each site?<\/h3>\n
Conclusion<\/h2>\n