The AAM and Campaign integration has two methods of identifying the same user in both solutions. One is using the MID or Experience Cloud ID while the other is using a Declared (or Customer) ID. As such, there is an AAM Data Source and Destination for each type of ID. While Adobe recommends using the Declared ID method, there may be a concern that the .sync files used for exchanging data between AAM and Campaign has the MID-based data source in the file name, even when using the Declared ID identification method with the Declared ID destination. Is this expected?
Yes, this is expected. The MID-based datasource in the file name has to do with the history of this integration. Originally, this integration only used the MID/ECID as the ID in the file exchanged with Campaign. However, Adobe learned that customers had much better audience sizes when they started using Declared IDs instead. This is why Adobe recommends using the Declared ID identification method. However, in order to preserve the initial integrity of the integration, it had to use the original data source for storing traits that came from Campaign, regardless of what identification method was used. The same is true of segments sent from AAM. Rather than having two different data source IDs for Campaign to look for, it made sense to just have the owner of the exported AAM data be the same MID-flavored data source. Even though the correct DeclaredId-flavored datasource is being used to put the correct IDs into the file, the “sending” data source is still the MID-based datasoure. The MID-flavored data source in the file name is just an organizational construct and isn’t related to which IDs are in the file itself.