In the first article in this series, I introduced the concept of sharing data in your digital marketing channels. To dive even further into the data landscape, let’s explore first-party data — what it is and how you can use it.
First-party data is information you own — data about users and their interactions directly with your brand that you get by tracking your own properties, not via another vendor.
This will typically include data collected when users are browsing your website, using your app, or when they become customers and hand over their name and address information.
Let’s examine them each in turn.
Web Analytics
This is an easy one, because you’re almost certainly already doing this. You have a few decisions to make about how to do it, though.
Most Web analytics packages use page-tagging methods — for instance, a snippet of JavaScript that collects the relevant information, then adjusts the page load so that the browser loads a single pixel image.
Within the URL that image is requested from are a bunch of parameters that contain the encoded information. The analytics package server turns those codes back into the original information and associates it with the page load.
This is a nice and simple mechanism, but it does rely on cookies to link the pageviews and visits together.
Cookies are so limited.
Which is a bit of a bummer, because cookies are so limited.
1. Cookies get cleared, killing all visibility of which sessions are linked together.
2. EU cookie laws mean various markets have different rules about what cookies you can store and what level of consent is required.
3. Some browsers (especially on mobile) simply don’t allow stored cookies by default.
4. People move between devices, but cookies are device- (and indeed browser-) level.
The limitations of cookies aren’t within the scope of this article, but it does impact how your first-party data gets collected.
The laws about what user data you can collect are a bit of a gray area (and different globally). But essentially if your privacy policy lets people know you’re collecting it, you give people an opt-out, and you’re very clear about this (i.e., it’s not hidden away super down in the small print), then you’re usually OK.
As people move between devices and browsers you’d like to keep those users tracked.
Many analytics packages will offer you the opportunity to link sessions together by using a consistent ID. You need to generate that ID when you know session A and session B are the same user, and upload it with the tracking pixel. By telling the analytics service that ID represents a user, those sessions can be linked as a single visitor.
This approach only works if people tend to log into your site. Even if only a small proportion of users log in this is still worth doing, because the trends you learn can help inform biases in the rest of your data.
App Usage
If you don’t have an app, feel free to skip to the next section.
User data collection through apps is similar to that on Web analytics, but with super powers.
Devices make all kinds of information available. Many apps ask for more permissions than they really need, and users can get a bit blasé about giving permissions. But if an app gets caught abusing them, a PR disaster will hit it hard.
It’s tempting to get permissions to learn a lot of things about your app users in the interest of improving your service. Don’t fall prey to that trap. Think about what information will be genuinely helpful.
An advantage of apps is that it’s more likely users will log in. The fact that they can log in once, retrieve their account, and stay logged in indefinitely encourages them to share that data directly and deliberately, no permissions required.
CRM
The best way to get information about your customers is when they give it to you.
The single best way to get information about your customers is when they give it to you, either by making a purchase, an inquiry, or otherwise willingly filling in a form or making a phone call that provides you with their name, phone number, email address, home address, or other similar pieces of information.
Totally separate from cookie regulations, data-protection laws put firm guidelines on what you can and can’t do with data given to you in this manner.
To summarize the most common rule around the world: You’re allowed to do with that data what people could reasonably expect you to do with it, given what you’ve clearly told them you’re going to do with it.
The power of customer relationship management (CRM) data is clear: With users’ purchase history, we have the clearest information of all about what they like. We know for sure that they’re the kind of customer who finds us interesting, and we know things like where they live, which can help us build an even better picture of those users.
Let’s Link It All Together
These three first-party data sources (Web analytics, app usage and CRM) are most powerful when linked together. If I have Web analytics goals that represent user engagement, send that information to my CRM.
If a user installs the app, make sure that fact is logged against that visitor in analytics, so that I can segment on app users versus non-app users.
The method to link these three sources is to find shared data fields. You can’t send Personally Identifiable Information (PII) to many analytics suites, so you’ll need to either hash it, or find another way to link a login to a randomly generated unique ID.
A hash is a one-way algorithm that converts text string A into text string B, but can’t be used to turn it back again.
So I can log and convert an email address a user has used to log into my website; I can convert an email address associated with a record in my CRM; and I can compare them to see if they’re the same. If they are, store the interesting parts of that browsing history with that CRM record, or import a purchase history into an analytics package.
A unique ID instead uses server-side code to create an ID randomly when the user first creates a record. That string is then recalled every time the user logs in. I never send the PII, only the ID, and only I have access to the database telling me which ID corresponds to which record.
Hashing is popular because I can then link it to second- or third-party data. If a user logs into a publisher’s website to download my white paper, that publisher can hash the email address and send it to me.
If they’re not my customer, I learn nothing. If they are, then I can add that to the user’s history — assuming the privacy policies of the publisher allow it.
Choose whichever method is most helpful to you, but in later articles in this series I’ll be talking about second- and third-party data in more detail.
If you want to learn more about importing and matching data in analytics packages, start with Google Analytics’ dimension widening and custom data import help articles.
Using Data In Inventive Ways
This all seems like a lot of work, so there have to be benefits to justify it.
The positive side is that there are more benefits than either you or I could list. The downside is that with so many benefits, I can’t easily help define your use cases. The following are some examples. As an exercise, try to expand on them for your own business.
• Targeting emails based on most recent website visit — Ping your CRM with the timestamp of every visit when the user has been logged in and can be linked to a CRM record, then you can either use that to trigger emails, or use the browsing data (e.g., “viewed more than 10 pages in the TVs category”) to adapt email content.
• App install remarketing only to users who don’t have the app — Any users who have installed the app can have a flag against their record, then when they log into the website that flag is used to signal a remarketing pixel to fire. Then exclude that pixel from your app install remarketing campaigns.
• SMS messages when a user is near one of your locations — If a user has purchased from you before, then you may have collected his or her phone number. When the location collection on the app signals they’re in your store, show them the best special offers and where to find them.
• Targeting broader keywords for users who live in your delivery radius — Anybody who has ordered from you should have their address in your CRM. If they’re in your delivery radius, fire a remarketing pixel next time they log into your website, and use that pixel for RLSA (Remarketing Lists for Search Ads) to broaden your keywords out.
All of the above only need first-party data, but require that information to be linked between systems, either tracking or media-buying systems.
Wrapping Up
First-party data is the easiest information to use, since you can gain consent directly from your customers. It’s easy to get into most media-buying platforms, and remarketing pixels are a ubiquitous way to achieve this.
It gets even better when it gets enriched by second- and third-party data, so we’ll look at those over the next two articles. In the meantime, start working out those clever, high-impact use cases that affect your business, and leave a note in the comments if you have a great idea.
Comments