OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

cxs message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [cxs] cxs meeting notes 20160428


Hello Jan,

Thanks a lot for posting this, since I was travelling this keeps me in the loop.

Actually this is similar to something I was imagining, because we will need to keep the relationship between the external system identifier and the context server profile identifier. Actually most external systems should not be required to be made aware of context server IDs as they probably don’t even know about it. So they need to be able to provide their own ID, and the context server must take care of associating with the data. Now the trick is really how do we merge this. We will need some type of mapping definition (such as an email address) or something to make sure we are merging the proper profiles.

cheers,
  Serge… 


On 28 avr. 2016, at 12:02, Jan Blessenohl <Jan.Blessenohl@telerik.com> wrote:

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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]