We finished part 3 defining the need of a customer identity provider that can seamlessly be integrated in all our touch points , but this also means that we can personalize our front ends only when our customers logins with our identity provider.
Can we personalize the appearance and the offers of our front ends without requiring the user to login?
If we look back to part 2 during the RTB the combined systems essentially do this job , because they recognize the user with a cookie or by device Id and they trigger the “right” advertising for him according to his profile (the real time auction is triggered only on the brands/campaigns that have this user profile in their target audience) .
In reality we can do even more than that, because of the following : while DMP can “see” the same customer as two or more different customers because he uses a laptop with different browsers and a smartphone (in reality DMP uses a very sophisticated algorithms to match cookies and devices ids with IP addresses and other variables to remove ,when possible, duplicates and build unified profiles…) since we have an identity provider in place , when the customer logins we can match the same identity Id with all the different device ids and cookies ids and target correctly the very same customer.
However again , we don’t want to build completely from the scratch such a complicated system, and there are options available on the market .
We can ,for example, leverage Google Analytics (GA) Id coupled with our Identity Id as GA Crm Id (some examples are listed here) and use this combo to provide personalization even when customers are not logged (ga Id–> Identity Id–> customer identified).
Of course we need to store this relationship somewhere and the nosql structure of the identity provider can be a nice place (but it will not be so simple as you can imagine 😉 ).
Another way to do it is to have the personalization/promotion engine directly integrated with a DMP and use the DMP segments to define the personalization on the front-end, but this, if we plan to leverage correctly our identity provider, it is not a good idea.
If instead you plan to have a “no-registration/login” website, this technique can be really useful.
Now if we assign to each customer one or more “tags” where , for example we say if the customer is Gold, Bronze or Silver:
and we write those tags directly into the identity record of the customer, what will happen it is that any front-end that is able to read from the identity provider , can also do personalization and promotions looking at those tags, right?
And since the identity is the same across all front-ends, we can have always the right personalization for our customers right?
Well in theory yes , in practice we need something more to achieve this:
1) A personalization / loyalty / promotion engine on the front end that usually reads from front end db
2) A push down operation that copies the “tags” from the identity provider to the local front end
3) A magic system that writes to the identity provider the “right tags” for each customer and also coordinates what “gold/silver/bronze” mean for all the various actors :
- what is the email template for a gold customer?
- what is the discount for a bronze one in the e-commerce shop?
- what silver means for the smartphone app?
If you pick the right identity provider and the right front ends the steps 1-2 should be only some minor configuration to do on the identity provider adapter for that front end.
Step 3 it is the holy grail of the overall landscape and we will look at it in the next part.