Troubleshooting mismatch mobile IDs when ID syncing

[TimeIndicator]

Hi,

I came across the below thread and was wondering how we would identify the destination partner's onboarding setup when it comes to mismatch ID setup.

Investigating match rates for server to server destination in Audience Manager

3. Mismatched IDs between partners

• Example: One could be onboarding mobile IDs using lowercase, while the destination partner could be onboarding IDs with uppercase (or the reverse)

Can you please let me know?

Thanks

[Ankita_Sodhi]

Hello There,

Thank you for reaching out to us.

I understand that it is hard to identify the data when it is coming from a 3rd party data provider but you can always make use of "Error Sampling" flag which will give you sampled data from the onboarded file under Onboarding Status Report.

This flag needs to be enabled for the specific datasource into which data is being onboarded and from the next data ingestion, you will be able to see this sampled information.

For more information about this flag, please follow this article.

To know more about onboarding status report, please follow this article.

I hope this helps, please let me know for any additional question on the given matter.

[Varun_Kalra · Accepted solution]

Hi there,

I believe now this point can be ruled out for onboarding Mobile Device IDs, as according to the recent updates in AAM, they have global device ID validation in place (Since March 2019).

GAID (Android device IDs) are all in lower case letters and IDFA always use upper case, and the number of characters are equal.
So, earlier we would be cautious while onboarding/collecting device IDs, now AAM takes care of that.

There was an announcement around March 2019 on Global Device ID validation, which was like following:

	Prior to this Update:
	Customers and partners can upload IDs to our global data sources in any format without being notified of whether the ID has been validated. This feature will validate device IDs that are sent to global data sources and will generate error messaging when any IDs are incorrectly formatted. Apple IDFA, Android GAID, and Roku IDs will be supported at launch.
	After this update:
	• Real-time: IDs are sent in real-time through DCS APIs via our JS libraries, SDKs or manually. If the ID is accepted it will be stored along with the traits that are realized against it. If the ID is not formatted correctly, a real-time error message will be generated. • Batch: For IDs brought in through batch, customers will see error messaging for incorrectly formatted IDs in the Onboarding Status Report.
	Customer Impact:
	This enhancement will be available for all Audience Manager customers without any additional resources required from Adobe’s Customer Care or Consulting services. To see the ID types and formatting that Audience Manager accepts, please visit our Product Documentation at the time of release. For information on how to validate your implementation to check that you are sending in properly formatted IDs, please visit our HelpX site or reach out to your Adobe consultant.

While exporting Mobile Data from AAM to S2S destinations (DSPs/Ad Platforms): I believe they should follow the global format as well. But, that needs to be checked with the partner platform.

Thanks,

Varun Kalra

[TimeIndicator]

Hi Varun,

Thanks for the info.  I have an another question.  If we have offline data and online data and let's say if the same user falls under both, would that trigger low match rate in AAM side of things when destination happens between AAM and an ad server?

• If mobile device ID and cookies are included in the same segment, match rates will seem low in AAM.

We are looking to troubleshoot on why our match rate has been staying at 60% and hasn't improved at all even though the offline and online audience scale is there and wondering reasons like ID matching issue might be an issue.  Any insights would help.

Thanks

[Varun_Kalra]

Hi there,

Thanks for replying.

That's an interesting question. But, that comment on mobile IDs and cookie IDs present in one segment is in different context. Lets keep that one aside.

Consider that you have a rule based trait for online and onboarded trait for offline data. They are being used in a segment that is mapped to an ad platform.

First, AAM segment population will always have device IDs (AAM Cookie ID). So, thats a good thing because there are no two IDs present (CRM and Cookie) in the segment, and all of these IDs are deduplicated.

Second, if segment comprises of an onboarded trait linked to a cross device data source, then segment must be using a Profile Merge rule.

Profile merge rule that uses current device as device option will take into consideration historical devices as well in segment. So your total segment population will have all those devices that are not recently active. It could be possible that there are devices in segment that are older enough and never had an id sync with ad platform. As ID sync for that ad platform gets enabled when you get S2S destination created.

Another reason could be: Ad platforms have TTL for their own IDs. Like AAM cookie ID TTL is 180 days and Ad Platform ID TTL could be 30 days or lesser etc.

I would recommend to log a ticket with AAM support team for further investigation. You could also request them to send a Full Sync file to ad platform on a more frequent basis.

Thanks,

Varun Kalra