Adding Attributes to Customer Insights
According to legend, Henry Ford once told a customer that he could get his Model T in any color he wanted “as long as it’s black.” That was simply a cute way of saying this: sometimes things are just what they are, and you don’t get to make a lot of choices or a lot customizations.
With that in mind, you could argue that Customer Insights 2.0, for all its incredible features, did share a few things in common with the Model T: neither one had air conditioning, neither one had built-in navigation system, and neither one offered users complete customization. For example, the Model T really wasavailable only in black from 1914 until 1926; meanwhile, Customer Insights 2.0 gave all users the same default set of attributes (covering properties like age, gender, and country of residence). Want a candy-apple red Model T? Sorry. Want to view a custom attribute in Customer Insights 2.0? Sorry.
Of course, there were legitimate reasons for customization being limited. In Ford’s case, buying one color of paint – in volume – was much cheaper. (And, according to another legend, black paint dried faster than other colors.) In the case of Customer Insights 2.0, user profile attributes were retrieved from the event stream, and events carry only a limited number of attribute values. Because there were only a limited number of attributes available, Customer Insights could only let you work with a limited number of attributes. You didn’t have much choice, because there wasn’t much to choose from.
With the release of Customer Insights 2.1, however, this has changed dramatically: you now have the ability to access any attribute from any of your entity type schemas. That’s because Customer Insights no longer relies solely on the event stream, but can now directly query the user profile store and return any attribute it finds there.
So does this mean that all your user profile attributes are available to you the moment you log on to Customer Insights? No. But it does mean that there’s now an easy way to make any attribute available, and, as a result, an easy way to customize CI in a manner that bests suits your needs.
There is one catch, however. Adding attributes applies only to the new “directory-derived” method of querying your user profile databases, which means that this does not apply to your legacy Explores. The original Customer Insights Explores, and their original attribute sets, are still available and can still be used; however, they’ve been marked as “beta” to indicate that, while useful, they are no longer the state-of-the-art method for retrieving data:
As it turns out, any attributes you add to Customer Insights will be assigned to the new entityType Profile Explores (for example, user Profiles). By default, these Explores ship with no default dimensions, and with only a single measure (User Count):
That also means that, by default, the only thing you can do with this new and improved way of querying data is to return your total number of users:
And that’s it. If you want to do anything else you’ll need to add some additional attributes to the appropriate Profiles Explore.
To add attributes to Customer Insights, start by contacting your Akamai representative and telling him or her what you’d like to do. In return, Akamai will export the schemas for all your entity types (or at least for those entity types containing attributes you want to add to Customer Insights). Akamai will then send you a spreadsheet (one for each entity type) that will look similar to this:
As you can see, there are four columns in this spreadsheet:
Each item listed here represents an attribute in the entity type. By default, all the attributes from the entity type are listed in this first column, and in alphabetical order.
A Boolean value that indicates whether or not you want the attribute to be available in Customer Insights; by default, this value is set to FALSE for each attribute, meaning that the attribute should not be available in Customer Insights. To make an attribute available, simply set include_in_ci to TRUE. For example, the following screenshot shows 5 attributes that have been marked for inclusion in Customer Insights (color coding added for emphasis):
In theory, you can include as many attributes as you want in Customer Insights. Before doing that, however, you should stop and ask yourself whether there is a valid business reason for adding a given attribute. For example, profiles.profile.bodyType.eyeColor is a valid Identity Cloud user profile attribute and, as such, can be added to Customer Insights. The question you need to ask, however, is this: do you really need to create reports based on user eye color? If the answer is no, then there’s no reason to add profiles.profile.bodyType.eyeColor to Customer Insights. After all, having too many attributes can needlessly complicate report creation and report viewing.
Along similar lines, you should also consider whether or not users have been supplying the data in question: maybe you do have a good reason to create reports based on eye color, except that only a handful of users have bothered to tell you their eye color. Likewise, you should consider how “clean” your data is before adding it. For example, perhaps you’ve given users the option of specifying their country of residence but you haven’t been validating those entries. As a result, you have entries like these:
- United St.
- Not telling you!
- United States of America
- I’m a man without a country
- The best country in the world!
- The States
Again, you might have a business need for creating reports based on country of residence, but if most of your data resembles the examples shown above, well ….
We should probably mention that, when adding attributes to CI, the dimension name in the Explore will be the attribute name. For example, if you add the email and gender attributes to the user Explore, your Explore will end up looking like this:
Indicates whether or not the attribute contains personally-identifiable information (PII). This is important, because Customer Insights can be used to limit exposure to PII: you can specify which users can actually view personally-identifiable information and which ones can’t. However, that sort of obfuscation can only take place if you specify which fields contain personally-identifiable and which ones don’t. For example, the screenshot below shows two fields – email and familyName–tagged as containing PII:
And what happens if an attribute is tagged as containing personally identifiable information? For the answer to that question, see if_pii_hash below.
Oh, and for attributes that don’ t contain PII, simply leave the default value (FALSE) as-is.
Indicates how personally identifiable information should be displayed. If set to FALSE, PII will not be displayed at all: if a Look or a Dashboard returns a PII field, that field will not be displayed (in other words, it will come up blank). If set to TRUE, that field will be displayed as a hash value; for example, a user’s email address might look like this:
It’s important to note that the preceding value is not just a random string of characters; instead, it’s an encoded value based on the user’s email address. That’s important to know because it means that any time you see the email address a2FyaW0ubmFmaXJAZW1haWwuY29t you know you’re dealing with the same user. You won’t know who that user is, but this does allow you to do such things as follow the user’s journey through your system.
In the following example, email has been set to display a hash value while familyName has been configured to not be displayed at all:
That’s all you need to know. Save the finished spreadsheet and return it to your Akamai representative; he or she will then take care of configuring Customer Insights for you.