This is a little story about the CDC Flow Builder and the way it can help you with progressive profiling.
The power of CDC lies in its ability to acquire the Zero-Party Data in a secure, compliant, and frictionless manner. This ability is enabled by multiple capabilities within CDC including the flexible data schema, screen sets, consent management and many more. Actually, we could argue that every single feature offered by CDC directly or indirectly contributes to the acquisition of the customer data.
The customer data to be valuable needs to be relevant, i.e., it needs to increase your insight and enable personalized engagements. In other words, the data you collect is only relevant if it extends your personalization abilities. Therefore, for every field you expect the customer to enter a value do make sure you clearly know how this piece of data will improve the way you engage with your customers; as an old saying goes: 'never ask a question unless the answer makes a difference'.
Of course, even the perfect customer data is of no benefit if it remains locked in CDC. To deliver the value you need to enrich the data with other sources, unify the profiles and activate real-time personalized experiences across your systems of engagement. For this Customer Data Platform (CDP) will come handy but this is a different story, and we shouldn't diverge from our topic...
So how to acquire these perfect customer profiles? The approach to embrace is progressive profiling.
Progressive profiling is a strategy to incrementally enrich the user profiles. With this strategy, the data is collected gradually over time and across customer journeys, as opposite to the approach in which the data is collected only at particular touchpoints. For example, with progressive profiling you can remove frictions from the most critical step in the customer journey which is onboarding. You do this by offloading the registration screens which chronically suffer from an inflation of mandatory fields. Asking too much upfront often results in the users abandoning the registration altogether. So, yes, you need to accept that you will not learn everything at the first interaction, and you will need to wait for all the necessary data. But your patience will be rewarded. Shorter forms with fewer mandatory fields will improve the UX and increase your conversion rates. In addition, since you can engage with the users at different steps of the journeys and use the knowledge you already have you can ask the right questions at the right time. By doing this you increase the odds of getting the answers.
(For more on progressive profiling do check Jenny's blog)
Progressive profiling strategy is supported in CDC by the Flow Builder – a visual tool allowing to implement identity flows. The flows can launch a single screen-set or a set of screen-sets to gather additional data from the users at any point in the customer journey.
The CDC Flow Builder offers the following controls of the flows:
In addition, an identity flows can emit events which can be captured within your site to trigger follow up actions, e.g., to execute subsequent flows.
Note:
Refer to SAP Help for more details.
Once the flow is published you will be presented with a code snippet you can use to plug the flow into your site at the chosen step in the customer journey. As soon as this is done any subsequent changes to the flow including deactivation happen only within the CDC console without any impact on your sites. This means you can rapidly deploy new versions of the flow, e.g., with amended conditions or different screen-sets. And although all this was possible with the WebSDK, screen-sets and your own code the Flow Builder with its low/no-code approach brings it to another dimension: it dramatically accelerates roll-out of the changes, reduces the time to market and allows composing the flows without in-depth technical knowledge.
-------------
To illustrate an E2E implementation of an identity flow we will look at the use case from our favourite company – Double-Y (DY). DY recently integrated their sites with CDC and implemented a central login page with a help of hosted pages (you can check it in this blog). DY want to enhance their journeys and present the customers with a screen asking for their favourite brand. The screen will be launched on login but only if this question is not answered. Also, the screen should be shown only once per day since we don't want to annoy their users too much.
The implementation can be broken down into the following steps:
(1) Enhance the schema
(2) Prepare the screen-set
(3) Build the flow
(4) Plug in the flow into the sites of both brands
The diagram below outlines how the main building blocks fit together.
We need the following two fields to be added to the schema:
Create a new screen-set with a field mapped to data.favBrand and Behavior = 'Edit Profile'.
Once the screen is loaded, we want to set data.flowDate to the current date. For this we will add something like this to the screen's onAfterScreenLoad event (for inspiration only):
Our flow is fairly straightforward and consists of the following elements:
We'll copy the code snippet from the Flow Builder and plug it into the onLogin events in our sites (for both brands). The code might resemble something like this:
Well, that’s it. Enjoy your newly implemented flow, happy (progressive) profiling & Happy New Year!
The power of CDC lies in its ability to acquire the Zero-Party Data in a secure, compliant, and frictionless manner. This ability is enabled by multiple capabilities within CDC including the flexible data schema, screen sets, consent management and many more. Actually, we could argue that every single feature offered by CDC directly or indirectly contributes to the acquisition of the customer data.
The customer data to be valuable needs to be relevant, i.e., it needs to increase your insight and enable personalized engagements. In other words, the data you collect is only relevant if it extends your personalization abilities. Therefore, for every field you expect the customer to enter a value do make sure you clearly know how this piece of data will improve the way you engage with your customers; as an old saying goes: 'never ask a question unless the answer makes a difference'.
Of course, even the perfect customer data is of no benefit if it remains locked in CDC. To deliver the value you need to enrich the data with other sources, unify the profiles and activate real-time personalized experiences across your systems of engagement. For this Customer Data Platform (CDP) will come handy but this is a different story, and we shouldn't diverge from our topic...
So how to acquire these perfect customer profiles? The approach to embrace is progressive profiling.
Progressive profiling is a strategy to incrementally enrich the user profiles. With this strategy, the data is collected gradually over time and across customer journeys, as opposite to the approach in which the data is collected only at particular touchpoints. For example, with progressive profiling you can remove frictions from the most critical step in the customer journey which is onboarding. You do this by offloading the registration screens which chronically suffer from an inflation of mandatory fields. Asking too much upfront often results in the users abandoning the registration altogether. So, yes, you need to accept that you will not learn everything at the first interaction, and you will need to wait for all the necessary data. But your patience will be rewarded. Shorter forms with fewer mandatory fields will improve the UX and increase your conversion rates. In addition, since you can engage with the users at different steps of the journeys and use the knowledge you already have you can ask the right questions at the right time. By doing this you increase the odds of getting the answers.
(For more on progressive profiling do check Jenny's blog)
Progressive profiling strategy is supported in CDC by the Flow Builder – a visual tool allowing to implement identity flows. The flows can launch a single screen-set or a set of screen-sets to gather additional data from the users at any point in the customer journey.
The CDC Flow Builder offers the following controls of the flows:
- Conditions: JavaScript expressions to determine the path of the flow allowing, e.g., to display a particular screen-set only if a given piece of data has not yet been collected or present follow-up questions depending on existing data.
- Time Period: time frame (until, during, from). For example, if you want to present a particular screen-set only within a particular time frame (e.g., a screen-set valid for a time-framed promotion).
- Counter: controls how many times the action will be executed. For example, you might want to present the screen only one time.
In addition, an identity flows can emit events which can be captured within your site to trigger follow up actions, e.g., to execute subsequent flows.
Note:
- The flows can be initiated only during a valid session, i.e., when the user is logged in
- You can only use screen-sets with Behaviour = Edit Profile
- An event positioned after a screen-set will be fired only if the user clicked the Submit button
Refer to SAP Help for more details.
Once the flow is published you will be presented with a code snippet you can use to plug the flow into your site at the chosen step in the customer journey. As soon as this is done any subsequent changes to the flow including deactivation happen only within the CDC console without any impact on your sites. This means you can rapidly deploy new versions of the flow, e.g., with amended conditions or different screen-sets. And although all this was possible with the WebSDK, screen-sets and your own code the Flow Builder with its low/no-code approach brings it to another dimension: it dramatically accelerates roll-out of the changes, reduces the time to market and allows composing the flows without in-depth technical knowledge.
-------------
To illustrate an E2E implementation of an identity flow we will look at the use case from our favourite company – Double-Y (DY). DY recently integrated their sites with CDC and implemented a central login page with a help of hosted pages (you can check it in this blog). DY want to enhance their journeys and present the customers with a screen asking for their favourite brand. The screen will be launched on login but only if this question is not answered. Also, the screen should be shown only once per day since we don't want to annoy their users too much.
The implementation can be broken down into the following steps:
(1) Enhance the schema
(2) Prepare the screen-set
(3) Build the flow
(4) Plug in the flow into the sites of both brands
The diagram below outlines how the main building blocks fit together.
(1) Enhance the schema
We need the following two fields to be added to the schema:
- Favorite Brand (data.favBrand) to capture the user's favourite brand
- Flow Execution Date (data.flowDate) to capture the date the flow was executed and the user was presented with the screen. We'll use it to build a condition in our flow to run it only once a day.
(2) Prepare the screen-set
Create a new screen-set with a field mapped to data.favBrand and Behavior = 'Edit Profile'.
Once the screen is loaded, we want to set data.flowDate to the current date. For this we will add something like this to the screen's onAfterScreenLoad event (for inspiration only):
// Called after a new screen is rendered.
onAfterScreenLoad: function(event) {
let currentDate = new Date().toJSON().slice(0, 10);
console.log(currentDate);
var params = {
data: {flowDate: currentDate}
};
gigya.accounts.setAccountInfo(params);
}(3) Build the flow
Our flow is fairly straightforward and consists of the following elements:
- Condition: the flow should continue only if we don't have the answer and if we haven't asked today. The condition could look in the following way:
data.flowDate != new Date().toJSON().slice(0, 10) && data.favBrand == null- Screen-set: here we'll plug in our screen-set
- Event: just in case we might need it in the future we will fire an event at the end of the flow (why not!)
(4) Plug in the flow into the sites of both brands
We'll copy the code snippet from the Flow Builder and plug it into the onLogin events in our sites (for both brands). The code might resemble something like this:
function onLogin() {
console.log("Flow Started");
const flow = gigya.flow('fav_brand').on('end', eventData => {console.log("Flow Ended");});
flow.execute();
}Well, that’s it. Enjoy your newly implemented flow, happy (progressive) profiling & Happy New Year!
- SAP Managed Tags:
| User | Count |
|---|---|
| 4 | |
| 2 | |
| 2 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 |
