Add attributes to reports
This article applies to the following Customer Insights roles: Developer
Customer Insights gives you the ability to access any attribute from any of your entity type schemas: the application can 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 that's OK, because there's an easy way to make any attribute available, and, as a result, 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 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 entityTypeProfile 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.
As noted, all attributes you add to Customer Insights are assigned to a Profile Explore: if you add 30 attributes to Customer Insights, your Profile Explore will then have 30 dimensions. At the moment, thereβs no way to take those 30 attributes and divvy them up between two or three different Explores.
This is also a good time to clarify that youβll have one Profile Explore for each of your user profile entity types. You say youβve got 7 different entity types? Then youβll have 7 different Explores. And, if you want, youΒ canΒ add a different set of attribute to each of those Explores.
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:
field
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.
include_in_ci
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, middleName 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 middle names? If the answer is no, then thereβs no reason to add middleName 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 middle name, except that only a handful of users have bothered to tell you their middle name. 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:
- US
- United St.
- America
- Not telling you!
- United States of America
- Iβm a man without a country
- The best country in the world!
- USA
- 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 also 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:
is_pii
Indicates whether 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.
if_pii_hash
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:
a2FyaW0vcmFmaXJAZW32aWwuLp9t
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 a2FyaW0ubmFmaXJAZW1haWwuY29tyou 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.
Updated over 1 year ago