To identify website visitors, CDP uses the following steps:
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.
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 can identify website visitors by leveraging this data. The unique identifier must be passed 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
SourceCustomerNumber
or Email
, even if the user is not
currently authenticated on the website. You can achieve this by using
identification cookie. Such cookies are set to any known user and can be
used on subsequent visits to the website. They behave similarly to cart
cookies that save the items that are currently in your cart even if you
leave the page to return after some time.SourceCustomerNumber
or Email
values must not be cached to
ensure that CDP accurately identifies the users generating the events.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 website to the customer profiles build through the customer feed.
Let us assume that CDP receives the following values:
SourceCustomerNumber | UUID | Source System | Name | |
---|---|---|---|---|
12345 | - | 12345 | Webtag | - |
A34567 | test@test.com | 12345 | Webtag | - |
12345 | test@test.com | 12345 | External Source | - |
A34567 | test@test.com | - | 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 | test@test.com | 12345 | ABC |
After you pass your visitor’s identification to enable CDP tie them to existing contacts, you can review the events that CDP tracks. For more information, see List of tracked events.