Data Layer Enrichment Call - Large Response

[ahrasch]

Hi,

I detected in our network traffic that the respones to the data layer enrichment public api (https://community.tealiumiq.com/t5/AudienceStream/Data-Layer-Enrichment-Public-API/ta-p/155) are sometimes as large as 2 MB. Most of this amount is from the replaces parameter. In the cited documentation I couldn't find any information about this parameter and so I have no clue about the reasons making this so huge.

Could you shed some light on this?

Best regards,

Andreas

[dan_george]

Hi @ahrasch,

The replaces parameter is related to Visitor Stitching. When two devices have been authenticated and the stitching process occurs, a new "primary" visitor profile is created that is the combination of the two device visitor profiles. This primary visitor profile will contain a "replaces" parameter that states which device profiles it should replace so that DLE reflects the combined (primary) visitor profile instead of only the device visitor profile.

If you are testing a lot of devices or clearing cache and cookies often, then this "replaces" parameter can grow to be rather large as it's reflecting all the different devices. This won't be typical of a normal visitor who uses only a few devices.

If you go to Discover > API Sampler and query on the Live Feed you can search the results for "replaces" and see if this is a common occurs for visitors, or just your user.

Please give that a try and let me know your results.

Cheers,

-Dan

[ahrasch]

Hi Dan,

I was indeed testing a lot in the last time. I used the API Sampler function now and didn't find a user, whose replaces parameter had more than one 45 character string. In the call I had earlier today, my replaces paramter consisted of at least 37000 strings.

So, is this really the expected behaviour? To me it looks like there is some exponential growth regarding the size, because I maybe deleted my cookies about 20 times and used only two different browsers. But if you say this is how it should be, I won't worry about this anymore. 

Kind regards,

Andreas

[dan_george]

Hi @ahrasch,

37,000 is definitely abnormal. This makes it seem like you have a default ID applied to visitors and all unathenticated visitors are being stitched together.

Can you provide the account/profile of your site (or you can email me dan@tealium.com) so I can look into this?

Thanks,

-Dan

[dan_george · Accepted solution]

To follow up on this issue:

The assumption that several visitor profiles were merged was indeed correct. The reason for this is the md5 hash of the userID (through the Tealium iQ Crypto Extension) invalidates the check in AudienceStream that the value exists. Meaning the extension sets this to the hash of an empty string, in this case (d41…27e), which means the "is assigned" or "is not empty" logic would be met. We are seeing the hashed empty string as the secondary_id in the visitor profile.

The Crpyto Extension does not currently allow a condition to be applied, so the fix is to add a condition to the Visitor ID rule in AS that the data source variable does not equal "d41…27e".