"S is not defined" Error in Adobe DTM - analytics

Question

I am in the process of migrating an existing Adobe anlytics implementation on s_code version 27.5 to DTM. The first step of the migration and what is in scope of the project is a pick up and shift job of the current s_code into AdobeDTM.
The site has multiple JS files that house functions that need the 's object' to be initialised to work, however s is being initialised in the s_code contents after most of these JS functions have run so is throwing errors for 'S is not defined'. It is not being initialised globally as it would be in a standard implementation.
Is there a way I can initialise 's' in the DTM satellite library globally. I have tried to add var = s{}; a page load rule under third party/custom tags area but only having intermittent luck with it, where sometimes getting errors thrown.
Any support/insight into this issue would be most appreciated.
Thanks!

Answer 1

Step 1: Change the Code Configuration to Custom
Note: If you migrated your legacy H code to DTM as a tool, then you should already be familiar with and already done this step, since DTM does not allow you to specify legacy H code for the "Managed by Adobe" option.
In the Library Management section of the Adobe Analytics tool, change the Code Configuration option to Custom, and Code Hosted to In DTM.
If you are using the legacy H code library, then you must also check the "Set report suites using custom code below" option. If part of your migration to DTM was to move to AppMeasurement library, checking this option is optional, depending on how you want to handle report suite routing.
Then, click the Open Editor button to open the editor. You should see the Adobe Analytics library in the code box. If you are migrating legacy H code, then remove everything currently in the box and add your legacy H code library (which you should have already done based on the question).
Step 2: Instantiate the s object
If you are using the legacy H code, then add the following line to the top of the code box, above the library:
window.s = s_gi("[report suite id(s)]");
You will need to replace [report suite id(s)] with the report suite id(s) you want to send the data to. s_gi() requires a value to be passed to it, which is why you must check the checkbox above.
If you are using AppMeasurement library, then add the following line to the top of the code box, above the library:
window.s = new AppMeasurement("[report suite id(s)]");
If you checked the "Set report suites using custom code below" checkbox, then specify the report suite(s). If you did not check it, then do not pass anything to Appmeasurement(). Alternatively, you can pass nothing, but also add the following underneath it:
s.account="[report suite id(s)]";
Note however in step 3 you will be setting it in doPlugins anyway so you don't really need this here (I just added this sidenote for other readers who may be migrating AppMeasurement s_code.js to DTM).
Note: Aside from the window.s part, you should already be familiar with this line of code, and already have logic for populating report suite(s), coming from a legacy implementation. Specifically, you may be using the dynamicAccountXXX variables. If you are upgrading to AppMeasurement library, then you will need to write your own logic to simulate that, since AppMeasurement (for reasons unclear to anybody) does not have this functionality.
Step 3: Setting report suite(s) after page load
One of the many caveats about implementing Adobe Analytics as a tool is that DTM (for reasons unclear to anybody) creates a new s object whenever an event based or direct call rule is triggered and AA is set to trigger. In practice, this means almost all of the variables you set within the custom code boxes in the tool config will not be carried over to subsequent AA calls on a page - report suite(s) being one of them.
What DTM does for report suite is set it to the specified Production Report Suite(s) if DTM is in production mode, or Staging Report Suite(s) if in staging mode. Even if you enabled the "Set report suites using custom code below" option!
To get around this, you will need to include doPlugins function (and usePlugins) in one of the tool's custom code boxes if you don't already have it included (you almost certainly do, coming from a legacy implementation), and you will need to also assign the report suite(s) within it (doPlugins and usePlugins do get carried over now).
For legacy H library, within doPlugins, add the following:
s.sa("[report suite id(s)]");
Note: setting dynamicAccountXXX variables within doPlugins will not work. You will need to write your own logic for passing the report suite(s) to s.sa()
For AppMeasurement library, within doPlugins, add the following:
s.account="[report suite id(s)]";
General Notes:
In the Library Management section, setting Load library at
Page Top will load the library synchronously at the position where
you put your DTM Header tag, which is the earliest you can trigger it
through DTM. However, this is not a guarantee the library will be
loaded before your other scripts that referenced it are executed
(e.g., references to s object in some other script tag above the
DTM Header script will continue to give you a reference error).
If you are indeed still using the legacy H library, then I would
recommend your highest priority be to migrate to AppMeasurement
library. Even higher priority than migrating the code to DTM, IMO.
While I echo Mark's sentiments about implementing AA code as a 3rd
party tag in general, the sad truth is in practice, it may still be
your best option at the moment, depending on your exact scenario. DTM
currently has too many caveats, short-comings, and outright bugs that
make it impossible to implement AA as a tool in DTM, depending on
your exact implementation requirements. Particularly when it comes to
making AA integrate with certain common 3rd party tools, and even
some of Adobe's other tools!

Answer 2

You will be better off if you migrate completely to DTM for analytics deployment rather than trying to reference the s object from legacy H page code.
If migrating completely from H-code to DTM is an option, I would do the following:
Remove all H page code and any references to s_code
Remove all calls to s.t or s.tl on links or pages
Deploy DTM Header / Footer code on all pages
Within DTM, Add the Adobe Analytics Tool
Within DTM, Add the Adobe Marketing Cloud ID Service
Within DTM and the "Custom Page Code" of Adobe Analytics tool, create the "do_plugins" section and add any custom plugins from the H-code.
Following these steps will allow the s object to be created within DTM and allow for all other rules to use it correctly.
What I would not do:
Deploy H-code (s_code) as a third-party script and try and reference the s object outside of the Adobe Analytics tool. This is not efficient and doesn't allow you to get the best practices from DTM, IMO.
Mark

Answer 3

One of the issues noticed using DTM to implement Adobe Analytics was with the S-Object being undefined.enter image description here
Reasons very much unclear.You have a workaround that I used by reminding DTM to set the S object again. In-cases where DTM does not recognizes what needs to be done.
var s = _satellite.getToolsByType('sc')[0].getS();
For my Implementation we had used a Third Party JavaScript that set within a Direct call rule and within which the above code was set.
The solution worked great ....