cxs meeting notes 20160428

Hi,

Thomas named it a break through, Chris was not sure, Kaloyan and Jan were smiling because their ideas were accepted. What happened?

We were discussing how the user can be identified in the event upload endpoint. We came up with the following proposal.

Event data can come from different sources like CMS, CRM, Mail shot systems, Forms tracking systems… Each system has a different implementation of User or Client Ids. Different types are used (integer vs. guid) and different number circles. Similar ids from different system can be assigned to different contacts. We want to support easy and error free upload from the browser as well as CSV export from the CRM followed by an CSV import to the context server. Also the back channel is important, CSV export from the context server can be used as a back channel to the CRM to update the lead status. We think that this makes it necessary to store a source dependent contact id in the context server. Here are the logical definitions:

1. The tracking id is bound to a source system, you have to request different tracking ids for different sources from the context server. Different sources can also be different top level domains.

2. The event collect endpoint accepts external contact ids bound to the tracking id specified.

3. The context server is generating, based on the mapping definition, a logical profile around the mapped external contact ids.

4. The logical profile id is used to identify a merged profile but should not be used to collect data.

Comments are welcome,

Jan

cxs message