Variable blacklisting

It is possible to collect any variable with Harvest Collect. Most variables are not personal identifiable, but some are. The reason you might want to use personal identifiable information is for user stitching.

Often you might want to classify your variables based on the impact they have on the privacy of the user. Collecting the event type for example has almost no impact on the user’s privacy. The email of the user, however, has a lot of impact on the user’s privacy.

Cookie consent

Another important aspect of Harvest Collect is the implementation of cookie consent. With the cookie consent functionality, it is possible to configure the different permissions a user can give.

Read our cookie consent documentation for more information.

Linking variables to permissions

As you can guess, it is possible to link variables to consent permissions. An often used persmission is personalization. This means, that if a user gives this permission, the company may use variables to stitch user behaviour across devices and platforms to create a personalized user experience.

How does it work?

So, the question now is, how does it work?

Step 1 - Define consent and permissions

First you will have to define your consent cookie and the permissions a user can give.

Step 2 - Link your permissions to variables

Then, you should configure your variables and link the variables to permissions. Note that if you do not link a variable to a permission, it means that the variable will never be blocked. You only need to configure variables that need to be blacklisted when a user didn’t give a certain permission.

Blacklisting variables

After your configuration is finished, you can test it by using our console debugging.

Let’s say you have defined the following permissions:

1. Functional
2. Personalization

We use the variable hashedEmail to stitch a user across multiple domains. We obtain the hashedEmail by setting the user’s email in the datalayer. The email will automatically be hashed. This is done by default. For more information read about email hashing.

An example would be a pageview when the user is logged in.

harvest.trackEvent({
    "event":"pageview",
    "data": {
        "email": "example@example.com"
    }
});

Note that you can change your consent with the harvest.setCookieConsent function. See an example below to set both a functional and personalization permission.

harvest.setCookieConsent({
    "permissions": {
        "functional":true,
        "personalization" : true
    }
});

After you have done this, you will see, when debugging the final event, that both the email and hashedEmail variables are in the userData object.

However, when you set personalization to false.

harvest.setCookieConsent({
    "permissions": {
        "functional":true,
        "personalization" : false
    }
});

And re-run the pageview with the email, you will see that email and hashedEmail are missing. This is the power of variable blacklisting.

Blacklisting query string parameters

It is not only possible to obtain information from the datalayer, but it is also possible to obtain information from query string parameter.

For more information, read the query string parameter documentation.

By default, Harvest Collect reads the harvest_he parameter. This parameter is linked to hashedEmail. So if you have blacklisted hashedEmail, you will also blacklist the parameter.

To demonstrate this yourself, visit the page: https://graindataconsultants.com/?harvest_he=123asdasd132. Then go to Chrome Developers tools and check the final event of the pageview.

You will notice two things:

1. In pageData.queryStringParameters you will find harvest_he only when you have set personalization to true.
2. In pageData.urlHref you will find harvest_he only when you have set personalization to true.
3. In userData you will find hashedEmail only when you have set personalization to true.

In the image above, take a look at pageData.queryStringParmaters, pageData.urlHref and userData. You will find both the harvest_he parameter and the hashedEmail variable. This is an example with consent.

On the image below, however, you will notice that both are missing. This is an example event where no consent was given.

Good to know, is that besides using variable blacklisting to filter query string parameters, it is also possible to actively whitelist parameters.

For more information, read the parameter whitelist documentation.