The purpose of this article is to provide some additional context and direction for deciding if the field you want to create should be a custom field on the golden record, a tag or an attribute.
When to add a custom golden record field
When adding a custom field to the Golden Record, you will be forced to choose one value to populate that field out of all of the source records within the golden record group. This value will be the “best” value and determined by the tiebreaker rules under the assemble golden record configuration. Therefore, if there is a field that may live in multiple sources but you only want to best value to be promoted to the golden record then you should create that field as a custom field on the golden record. An example of this might be secondary email.
If you want additional values for this field to be available on the golden record than you can either create additional custom fields or consider using string attribute for these fields (see more on this topic below). An example of where you may want to create more than one custom golden record field could be credit card number. In this case you may have several credit card numbers for a single fan and you want more than one to live on the golden record then you should consider creating multiple fields.
All golden record fields, including custom ones, can be used in your matching rules for determining golden record groups. Therefore, if there are data points that could be used to identify a fan and you may want to leverage those fields in the matching rules then you will need to create a custom field on the golden record for that data point.
One last consideration when deciding if you should create a custom field on the golden record is you data structure. If the field you are planning to add to the golden record already lives in the same contact dimensional table as the other key personal identifying information (PII) fields then it will be easy to add to your SQL definition for the Helix data set. However, if that value leaves in another table or needs to be aggregated to a different level of detail in order to join back to the PII table then it would be easier to create an attribute for that value instead of adding it to the golden record.
When to create a tag
Tags are similar to the concept of a Microsoft Dynamics marketing list or a Salesforce campaign members. Tags represent membership of a specific group as defined by your SQL statement. Tags answer the questions: does this record have a specific quality or has this record interacted with us in a specific way? Qualities and interactions of customers change overtime just like membership to a specific group will change over time. Tags are a great way to track who belongs to specific groups. Some example of this would be “current season ticket member”, “at risk for renewal” or “upsell target.” Each of these examples are defined by the actions a customer takes. Has the customer purchased a specific product, like a season ticket? If so, then they belong to the “season ticket member” group. Has the customer’s ticket utilization been declining? If so, they may belong to the “at risk for renewal” group. Has the customer bought a lot of additional single game tickets and or increased their total spend across non ticketing categories? If so, they may belong to the “upsell target” group. Since all of these are qualities that are based on interactions and can change over time, these qualities are better to track as Tags instead of custom golden record fields.
Additionally, it is important to note that Tags are attributed to a single source id within the golden record grouping. This means that a single golden record group could have different source records with different tags and all the tags for each of the source records within the group will be shown on the golden record. This behavior is different from custom fields on the golden record because custom fields require to to select a single value out of all of the source records via the tiebreaker rules.
When to create an attribute
Typically, values that live in transactional tables or outside of the contact dimension tables within your database are easier to represent as an attribute over a custom golden record field. This is because you will likely need to preform a calculation, aggregation or pivot the data in order to bring the value to the right level of detail to join back to the customer record. Since attributes can be calculated or aggregated data, their values can be stored in different data types, such as numeric, date time, or string. Examples of attributes could be “current season ticket spend” as a numeric value, “latest transaction date” as a date time value or “top ticket group” as a string value.
Just like tags, attributes are calculated or aggregated to a single source id within the golden record group. Therefore, you could have multiple values for current season spend for each ticketing id within the golden record group.
Additionally, pulling demographic fields from archtics or live analytics you have need to pivot your data with multiple left joins based on how the data is structured. If this is the case it would be easier to use an string attribute than a custom golden record field.