Incremental Data Capture
In incremental data capture, we ask for additional information from end users in exchange for more access to content. This is known as a key-value exchange.
A key-value exchange is where a business and a customer swap something of value that benefits both parties. This is often where an end-user spends money to buy a subscription. In this example, we look at another use case; where the business gains more knowledge about their end-user, while the end-user gains further access to content. This key-value exchange allows you to personalise the end user’s experience, and build loyalty through increased use of your product.
For example, we can use incremental data exchange as follows:
- The end user registers on your site and provides their email address
- You provide the end user with two free views of your content
- When the end user has viewed their free content, you ask them to provide their first and last names
- The end user supplies the information
- You provide the end user with two further free views of your content
You can continue this exchange, requesting further information in exchange for more free views of your content; or, you could use it as a taster of your content quality before asking the registered user to subscribe. For more suggestions on the ways you can build up your data capture, see the Iterations section below.
This approach lowers the end user’s barrier to entry, as they are asked for minimal information each time in clear, minimal forms. It also allows you to build a clearer picture of your end users, which helps you increase ad revenue or generate a more qualified leads list for your sales team.
Prerequisites
Before you start this example, ensure that you have set up the following:
- Either comment tags added to your article content, or knowledge of the CSS selector that you can use to add a rule.
For further information on using comment tags, see the Comment Tags Use topic. For further information on using CSS selectors, see the CSS Selectors Use topic.
- User attributes
For this example, we use an attribute to collect the end user’s first name. For further information on managing user attributes, see the User Attributes section.
- Your payment provider
For further information on setting up your payment provider, see the Payments topic.
- A product that is linked to an Article feature
For further information on managing products, see the Catalogue section.
Main steps
In this example, we do the following:
- Build an anonymous user journey, which displays a registration wall asking for an email address and provides them with two free content views if they register
For further information on building the anonymous user journey, see the Build the Anonymous User Journey topic
- Build a registered user journey, which does the following:
- After the register user has used their two free content views, displays a data capture form that asks for the user’s first name
- Grants a further two views of article content to registered users who supply the information, and presents a paywall after they have viewed their further free content
For further information on building your registered user journey, see the Build the Registered User Journey section.
Understanding these journeys provides the tools and techniques that you need to build your own data capture wall, and to add further logic to personalise your user journeys.
Iterations
You can iterate this example in many ways, and you can create all your iterations in Zephr. This example shows a basic way to offer trials that ask for the end user’s first name. You could use the same techniques to offer further trials in exchange for more information.
For example, you could ask your users to do the following:
- Register with an email address
- Display a data capture form to collect their First Name and Last Name in exchange for further views
- Display another data capture form, which asks for their Job Title and Company, or City and Country, in exchange for more free content views for each completed form
To create these iterations, add sub rules after each granted trial that ask for different information. Remember to test the rule before going live.
You could also add a split test to the rule to test conversion rates for users providing additional information against those hitting a Paywall after the first Trial.