Expand my Community achievements bar.

Help shape the future of AI assistance by participating in this quick card sorting activity. Your input will help create a more effective system that better serves your needs and those of your colleagues.
SOLVED

AppMeasurement (s_code) in DTM Question

Avatar

Level 6

We are currently using modified s_code in DTM but I would like to revert back to "managed by Adobe" however I had a few questions regarding the custom code we have in the s_code file:

1.JPG

Custom Code in s_code:

  • Using the YouTube API for video tracking
  • DemandBase code from Data Connector
  • doPlugins for:
    • getPercentPageViewed
    • getNewRepeat
    • getVisitNum
    • getLoadTime
    • getTimeParting

Questions:

  1. Can I migrate the YouTube API, DemandBase API and the doPlugins to the "Customize Page Code" section?
  2. Any other workarounds to get the custom code to still work but have s_code managed by Adobe?
  3. If I can use the "Customize Page Code" section then when would I execute, "After"?

2.JPG

Thank you in advance for any help,

Scott

1 Accepted Solution

Avatar

Correct answer by
Level 1

Hi Scott -

I think migrating to Adobe Managed App Measurement is a smart idea. The configuration you've described is most likely a legacy implementation, and with few exceptions, is not necessary. This setup also has the potential to cause issues with the implementation as it scales.

The best way to migrate is to move all "do_plugins" code to custom page code (as you've indicated) and leave the default execution settings.

If you need to migrate 3rd party tags and are concerned about load timing, I would add each tag separately as 3rd party JS (for better control and management) and then decide, based on each tag, if you will need to configure the load of the tag (top of page, asynchronous, page bottom, etc).

Hope this helps.

View solution in original post

2 Replies

Avatar

Correct answer by
Level 1

Hi Scott -

I think migrating to Adobe Managed App Measurement is a smart idea. The configuration you've described is most likely a legacy implementation, and with few exceptions, is not necessary. This setup also has the potential to cause issues with the implementation as it scales.

The best way to migrate is to move all "do_plugins" code to custom page code (as you've indicated) and leave the default execution settings.

If you need to migrate 3rd party tags and are concerned about load timing, I would add each tag separately as 3rd party JS (for better control and management) and then decide, based on each tag, if you will need to configure the load of the tag (top of page, asynchronous, page bottom, etc).

Hope this helps.

Avatar

Level 10

Hi Scott,

I agree with Mark's answer. One additional thing that you might run into is scoping on the s object. If you do, we have some workarounds that will globally scope the s object. Let me know if you run into that and I'll see if I can find the latest recommendation.

Cheers,
Jantzen