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.

Dynamic rsid – the official way
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.


  • the officially supported method
  • pretty straight-forward


  • 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);


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


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


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.

Dynamic rsid Data Element
Dynamic rsid DE Code
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?

10 thoughts on “Dynamic Report Suite ID with DTM

  1. Hi,
    Thank you for the info.
    A few weeks ago (i.e. point 1) I moved away from the built in functionality solely because to allow the lib maintenance free of hassle. I add the s.sa() method in the code editor of the Analytics tool. s.sa added on top and another one in the s_doPlugin function to cater for s.tl().


  2. Hey there,

    Where and how do I actually reference the new variable in the AA tool and the rules/tags? Do you just set s.account = rsid in the Customize Page Code sections? Thanks.


    1. Hiya,

      I personally use option 2, i.e. i use s.sa() and a Data Element, inside doPlugins.

      That means that the AppMeasurement library might originally be initialised with an rsid that will never be used, but I don’t think that matters.


      1. Thanks Jan, for now we ended up with this in the AA tool customization, where ‘Report Suite’ is generated as a data element depending on hostname:

        rsid = _satellite.getVar(‘Report Suite’);
        s.account = rsid;

        And yes, the initial AA configuration is ignored but required for the AA tool tag to initialize. Let me know if you have any insights on this setup.



  3. Hi Jan,

    How can we configure Analytics to automatically select a Report Suite ID in Adobe Launch analytics extension?
    Could you please help me with this.


    1. Hiya,

      Can you be more specific? How do you want to automatically select a report suite id?

      You can use Data Elements in Launch, even for the rsid. That covers a lot of use cases, in my experience…



Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.