Should I have one DTM property, or many?

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 my advice is to keep as few properties as possible- it’s so much easier to maintain.

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 consider the following:

How similar are the implementations?

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?

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.
Imagine 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.
If, 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.

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, but in general, plan on Tools in DTM running on every page, without being able to suppress them for certain pages.

How similar are the publication timelines?

Will one site go live with the Analytics tool sooner than another? Does another site have a lengthy QA process?  Would it be ok to publish changes in DTM that will push out to all sites at once?

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. If the plan to transition to DTM really 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.

Who will be doing the DTM work for each site?

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? 

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.

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

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

Conclusion

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. Hopefully this post will help you decide on the best possible arrangement for your company.

7 thoughts on “Should I have one DTM property, or many?”

    • I don’t think so. You can set up something in your s_code that sets currency code dynamically:

      s.currencyCode=_satellite.getVar(“currency code”)

      And just make sure your “currency code” data element is set properly per site. That’s not to say having multiple properties may not still make the most sense, but I wouldn’t think of currency code as a deal breaker.

      Reply
  1. Hi Jennifer,

    I googled this question and your post came up. Maybe you can share some info:

    If I have 2 separate DTM properties, and I use the same s_code file for them, will the sessions be continuous and stitch together? e.g. eVars and tracking codes set in the first property are given credit for conversions on pages with the second?

    Your site is great btw!

    Reply
    • Thanks, Andrew!
      Session/visitor identification actually isn’t tied to your DTM property, or even to your s_code, but rather to how your cookie settings and report suites are. Let’s take this example:
      user comes from paid google keyword -> domainA.com page views -> domainB.com conversion
      If you want the paid google keyword to get credit for the conversion, first off, you’d need to send the data from both domains into the same report suite. Otherwise, nothing will ever get that full picture of the user experience.
      So assuming you have all the data you want to tie together in the same report suite, next you need to make sure you are using the same method to identify the visitor in both places. If both your DTM properties are use the same overall domain, then we have no problem. If not, you may need to move away from some of the default settings.
      I’ll assume you’re using the Visitor ID API (though this all applies pretty well to the old s_vi cookie approach too). By default, that API is going to want to set the visitorID cookie as a first party cookie. In my example scneario, this is a problem, because that’d mean the API sets one cookie on domainA, then when I go to domainB, the visitorID service looks to see if the user has already been identified, doesn’t see a cookie on domainB, and sets a new cookie on domainB. Now our user looks like two different people, because there are two cookies each with a different ID on them. So, I have a couple options. One, would be to use the CNAME approach (https://marketing.adobe.com/resources/help/en_US/mcvid/mcvid_cname.html) to tell the API to always set/look for the cookie on domainA.com. This is great on domainA- it’s a first party cookie! But if tell Adobe to set/look for a domainA.com cookie on domainB.com, it becomes a third-party cookie. We can pretend it isn’t so bad by calling it a “friendly third party cookie” but the rejection rates can still be pretty high (20% is a very rough/potentially obsolete estimate).
      Alternatively, you can use “appendVisitorIDsTo” (https://marketing.adobe.com/resources/help/en_US/mcvid/mcvid-appendvisitorid.html) on any links that take the user from domainA to domainB. This takes the ID set on the domainA.com cookie and passes it via query string to domainB, where it can be stored in a domainB cookie. The major downside here is you have to: 1) make sure all your links from domainA to domainB (and back) have this logic on it, and be ok with those visitorIDs appearing in your URLs, and 2) not have too many scenarios where the user goes google>domainA>google>domainB… since you’re not in charge of the link that is leading folks to domainB (google is) you can’t append that visitorID to it, and they’ll look like a new visitor on domainB.

      Either approach exists independently of s_code or DTM property- though, of course, you’d need to make sure whatever approach you go with is set up properly within either DTM property/any s_code you are using. Hope that helps!

      Reply
      • Thanks Jenn! – This is an extremely helpful answer and sheds a lot of light on the complexities of tracking cookies.

        Reply
  2. I have multiple domains setup on a single property and used Tools to deploy Adobe Analytics. I set the reportsuiteID in the form field, which consequently is setting all domains to the same reportsuiteID, which I don’t want. What’s the best way to dynamically set the reportsuiteID for each domain? I’m thinking adding custom page code to set s.account by domain. Would this be the right approach?

    Reply
    • I believe in Launch, you’ll be able to set the RSID with a data element so you could dynamically set it, but currently, I don’t think that’s an option.
      If you are willing to maintain your own s_code, you can set your RSDI in there dynamically, or you could do this in the Custom Code section of your adobe analytics tool. Be careful if you do the latter, though- I want to say I’ve seen some odd things happen on EBRs and DCRs when the RSID in the interface is different from the one in custom code sections unless you are defining your own s object.

      Reply

Leave a Comment