The following are the steps to identify website visitors:
Identifying visitors through a unique ID
If a visitor lands on your website from an external source, the source must send a unique ID for that visitor to your website. This can be sent in the redirect URL, cookie value, or any other web pass mechanism. You must store this unique ID on the website and persist it across the session cookie. Acquia recommends that you persist the unique ID information for a browser session.
Sending the unique ID information to CDP
After you receive the information from the external source, you must forward the same to CDP through the CDP WebTag library or DW Tracker API. CDP identifies the website visitors by leveraging this data. You must pass the unique identifier in the payload of the HTTP call based on the authentication status of your website visitor.
User is logged in to your website:
customer: { SourceCustomerNumber: <Unique ID linked to the email value. The format of this parameter varies for each tenant. For example, 360profile_customer_13.> UUID: <Unique ID. For example, 12345.> Email: <Email used by the visitor to log in to the website. For example, [email protected].> *Other data points in this object remains same as desired* } event: { SourceCustomerNumber: <Unique ID linked to the email value. The format of this parameter varies for each tenant. For example, 360profile_customer_13.> Email: <Email used by the visitor to log in to the website. For example, [email protected].> *Other data points in this object remains same as desired* }User is not logged in to your website:
customer: { SourceCustomerNumber: <Unique ID. The format of this parameter varies for each tenant. For example, 360profile_customer_13.> UUID: <Unique ID. For example, 12345.> *Other data points in this object remains same as desired* } event: { SourceCustomerNumber: <Unique ID. The format of this parameter varies for each tenant. For example, 360profile_customer_13.> *Other data points in this object remains same as desired* }
Important
If CDP is able to identify the website visitor during the same session, all anonymous events are associated with the known user. CDP defines a session as a 30 minute window before or after identification.
If you have already integrated CDP WebTag with your system, you must try to send
SourceCustomerNumberorEmail, even if the user is not currently authenticated on the website. You can achieve this by using an identification cookie. Such cookies are set to any known user and can be used on subsequent visits to the website. The cookies behave similar to cart cookies that save the items that are currently in your cart even if you leave the page and return after some time.The
SourceCustomerNumberorEmailvalues must not be cached to ensure that CDP accurately identifies the users generating the events.
Sending a customer feed with various customer attributes
The external source integrated with your system must send a customer feed with all the desired customer attributes. This helps CDP to build the customer profile. CDP can link the behavior from the website to the customer profiles built through the customer feed.
Sample explanation
Let us assume that CDP receives the following values:
SourceCustomerNumber | UUID | Source System | Name | |
|---|---|---|---|---|
12345 | - | 12345 | Webtag | - |
A34567 | 12345 | Webtag | - | |
12345 | 12345 | External Source | - | |
A34567 | - | Customer Data Source | ABC |
CDP maps the preceding values from Customer feed - External Source to both SourceCustomerNumber and UUID.
This results in the following customer summary record:
Master Customer | UUID | Name | |
|---|---|---|---|
12345|A34567 | 12345 | ABC |
Next Steps - List of events that CDP tracks
After you pass your visitor’s identification, you can enable CDP to tie the identification to the existing contacts. You can review the events that CDP tracks. For more information, see List of tracked events.