supplementalDataId Different For Each Adobe Target Request

Avatar

Avatar

kaiomo

Avatar

kaiomo

kaiomo

19-12-2020

 

Hello,

 

We have a activity only for visitors with a particular profile parameter. But this data point does not exist until several seconds after the page has fully loaded. This means the first pageLoad request made to Adobe Target (at.js 2.x) is missing these parameters - and the visitor fails to qualify for the test.

 

We have some code that will scrape the DOM for all the necessary data points, so we want to make a second request to the Adobe Target servers. This time with all the parameters in order to fetch the activity and then apply it.

 

For A4T to work correctly all calls to Adobe Target should use the same supplemental ID as the original Adobe Analytics Page track supplemental ID. This works fine for the default first pageLoad request.

 

But when we try to make this second request using adobe.target.getOffers and a hardcoded supplementalDataId it is ignored, and instead a new supplementalDataId is created.

 

How can we ensure the supplementalDataId isn't randomly recreated, and instead uses what we set it to?

 

 

 

 

    adobe.target.getOffers({
            request: {
                experienceCloud: {
                    analytics: {
                        supplementalDataId: "4A3B4159AD0B6F95-7F996DA189DD5694" // hardcoded to test if this gets passed to Adobe Target
                    }
                },
                execute: {
                    pageLoad: {
                        parameters: {
                            level: 'advanced'
                        },
                        profileParameters: {
                            score: 2 // example parameter that we scraped from DOM several seconds after page loaded
                        }
                    }
                }
            }
        })
        .then(response => adobe.target.applyOffers({ response: response }))
        .then(() => console.log('Success'))
        .catch(error => console.log('Error', error));

 

 

 

 incorrectId.png

We have manually ran the above code snippet in the console, and expected the network tab to show the same supplementalDataId as we have hardcoded. But it wrongly showing as '7F3635E16781A866-10994B8473BC3DE7'

 

References;

https://experienceleague.adobe.com/docs/target/using/integrate/a4t/troubleshoot-a4t/a4t-troubleshoot...

https://experienceleague.adobe.com/docs/target/using/implement-target/client-side/functions-overview...

https://developers.adobetarget.com/api/delivery-api/#operation/execute

 

Accepted Solutions (0)

Answers (2)

Answers (2)

Avatar

Avatar

kaiomo

Avatar

kaiomo

kaiomo

31-12-2020

Thank you @shelly-goel 

 

Just tried with a local mbox and a new sdid is being generated. Would also rather avoid using logging:client_side

 

It seems the sdid is decided by a function called getSupplementalDataID - and there are two in circulation at any one time (stored in visitor._supplementalDataIDCurrent or visitor._supplementalDataIDLast). If I override those values I can force my getOffers request to use the sdid of my choosing (the same one that was used for pageLoad and Adobe Analytics page view call).

 

Is there a limit on the number of times a sdid can be used?

 

For example;

  1. Default pageLoad (sdid = 12345ABC ; adobe takes care of this itself)
  2. Analytics pageView (sdid = 12345ABC ; adobe takes care of this itself)
  3. My getOffers(execute:mboxes)+applyOffers call (sdid = 12345ABC ; i have forced getOffers to use this sdid)
  4. Another getOffers(execute:mboxes)+applyOffers call (sdid = 12345ABC ; i have forced getOffers to use this sdid)

 

Will Adobe be able to sync that all together on the server so I can use Adobe Analytics as reporting source?

Avatar

Avatar

shelly-goel

Avatar

shelly-goel

shelly-goel

28-12-2020

@kaiomo 

There should be 'marketingCloudVisitorId' present as well for A4T. Having said that, with pageLoad a new hit is generated and so a new sdid (there would be another analytics call too having same new sdid).
I would rather suggest to delay setting target parameters and so the global mbox call until the profile parameter (score) is available so that a single page load event is generated (with the experience) once all params are available. No additional getoffer() and applyoffer() would be required.
If it's not feasible to delay page body load then it would be better to create a different local mbox (which can be retrieved with getoffer in execute:mboxes) than global mbox (which is specifically for experiences on page load, default content would have been already rendered).

If you still want to keep global mbox and same sdid, you can rather control the analytics call client side (logging:client_side).