Dynamic Report Suite ID with DTM

Adobe Analytics has always had a feature that allowed you to dynamically set the Report Suite ID (rsid). It works with a list of domains, matched against the current domain automatically. See dynamic accounts in the Marketing Cloud Help.

Nevertheless, traditionally, people have built their own code to set s_account before loading the s_code.js file. It used to be straight-forward to do. Then along came DTM (the core service now known as “Activation”), and all of a sudden there were multiple options.

Every consultant I know uses one of those options pretty consistently, and we all have good reasons, I guess. But since we all stick to our favourite, how can we know it is the best?

I know! I’ll list them! With pros and cons!

The following list might be incomplete, so if you know of another way, please share it in the comments!

1 — DTM built-in

DTM itself has a checkbox in the setup of the Adobe Analytics tool.

What happens if you tick that box?

For a start, you have to switch to custom library management to even get the box to show up. Meaning no easy updates to the latest library for you!

If you check the box, DTM will go through your library code (the one that you manually provide), look for a variable called s_account, and read the rsid or rsids from this variable.

Pros:

• the officially supported method
• pretty straight-forward

Cons:

• you lose easy updating of the library

2 & 3 — doPlugins

The Analytics Javascript libraries come with a function that allows you to switch rsids at any time: s.sa()

Combine that with a doPlugins() method and you can essentially change where each hit should be sent to.

My approach to this is to create a Data Element (see below), then simply add a call to s.sa() in doPlugins like so:

	s.sa(_satellite.getVar("Report Suite ID"));

Or, if you like it verbose:

	var rsid = _satellite.getVar("Report Suite ID");
	_satellite.notify("Setting rsid to " + rsid, 1);
	s.sa(rsid);

Pros:

• uses documented functionality
• as flexible as it gets
• changes happen in one place
• automatic library updates (for 2)

Cons:

• not transparent
• you lose easy updating of the library (for 3)

The disadvantage of this approach is that it is not easily visible, in a “jumps at you when you look at the configuration” kind of way. If you do a setup like this, and you hand over to someone at some point, make sure you document this! Like a lot! Sticky notes and stuff!

The fact that you’re using a DE makes it really easy to build tests for this, btw. I’m talking about automated tests, the ones that run before any deployment. Make these tests, and you won’t have to worry about the disadvantage at all.

Where is doPlugins?

A colleague of mine uses manual management of the library, and he includes a doPlugins method into this.

Myself, I use the Customize Page Code editor in the Analytics tool to define doPlugins. I’m sure there are pros and cons for both methods. Look forward to another article, soon in this theater!

I call my method 2 and my colleague’s 3.

4 — Custom Code in Every Rule

The naive approach would probably be to use the Custom Code editor in each and every rule, use a Data Element and s.sa() in there.

But even though I am a bit naive, I wouldn’t do that. It would be a major PITA to change the report suite IDs should the need ever arise.

So let’s forget about this one.

How not to do it

You might be tempted to use manual library management or the customize page code editor to set the report suite ID.

This will work for your Page Load Rules, but as soon as you start to use Event-based Rules or Direct-call Rules, it’ll fail.

DTM creates a new tracker for those rules, and those trackers will be initialised with the rsids configured in DTM.

The same goes for using a PLR with Custom Javascript code. You can call s.sa() in a PLR, but there is no guarantee that DTM won’t create a new tracker and therefore ignore your change.

Notes

Open question: where do I actually get my dynamic rsid from?

I’d personally suggest you use a Data Element for that.

If you look at any deployment that I have touched, you’ll likely find a DE called “Report Suite ID”, which when called will look at things like the domain (is this the productions site or some staging server?) and whether DTM is in staging mode or not.

I like using a DE, because it centralises the code that determines the rsid. Should you ever need to change the logic, you only have to change the definition of one DE.

Btw, the DE can be used with some, but not all of the methods above. In my mind, that kind of rules out the other methods. But that’s just me being idealistic; I’m sure there are situations where the other methods apply.

And for your convenience, here’s the tl;dr, in tabular form:

#	Method	Supported	can use DE	automatic library management	possibility of race conditions	PITA
1	Official DTM	👍	👎	👎
2	doPlugins (Customize Page Code)		👍	👍	👎
3	doPlugins (Manual Library Management)		👍	👎	👎
4	Custom Code in Every Rule		👍	👍		👎

Which one do you use? How does it work for you? Any thoughts?