Golden Record

Golden Record provides a unified profile of each identity that Identity Resolution (IDR) resolves in two forms:

1. A flattened table written directly to your data warehouse
2. An auto-generated parent model and schema in Customer Studio (if you have Customer Studio enabled)

Instead of working directly with all identifier values for each profile, the Golden Record table and parent model provides the single best or primary value per field.

By having a clean, deduplicated table for each customer, you can quickly:

• Segment users by your most up-to-date and trusted trait values
• Sync these traits into your marketing or sales tools
• Give non-technical stakeholders (for example, marketers) a single, easy-to-understand table to build audiences from

How Golden Record fits into the IDR outputs

When IDR runs, it typically writes the following tables back to your data warehouse:

1. <output_prefix>_resolved: All rows from your input models, each labeled with an HT_ID (the unique identifier for your profiles).
2. <output_prefix>_resolved_identities: Each profile's unique identifier values (for example, all emails for a user).
3. <output_prefix>_unresolved: Rows that were skipped if primary keys weren't unique in your input models.

Golden Record introduces a fourth table, <output_prefix>_golden_records, containing:

• HT_ID: A unique, stable reference to the identity
• One flattened column per identifier (for example, email, user_id, phone_number), chosen via survivorship rules
• Additional columns based on additional survivorship rules you define

This approach gives you a clean table and model that has 1 unique row or record per identity and columns and fields for each identity defined by the survivorship rules you define.

Why use Golden Record?

1. Simple audience creation

Golden Record will automatically generate a parent model and schema in Customer Studio so you don't have to wrangle with SQL to manually define models for Customer Studio using the IDR output tables. The schema will automatically have all of the data you feed into IDR linked to the parent model which is defined by the identities IDR resolves and the survivorship rules set in the Golden Record feature.

2. Easily extensible profile

Fields like lifetime_value or membership_tier can be easily defined using Traits on the parent model generated by Golden Record, without additional stitching or SQL queries.

3. Less manual SQL

Previously, you might have written custom SQL to choose the "most recent" or "most frequent" trait and flatten them into a single table. Golden Record does this automatically, based on intuitive survivorship rules you define in the UI.

Configuring Golden Record

You can configure your Golden Record in the tab named as such within an identity graph page:

1. Open your identity graph
   Go to Identity Resolution and choose the graph you want to enhance with Golden Record.

2. Go to the "Golden Record" tab
   You'll see a list of all identifiers recognized by your IDR project and an option to add additional columns that aren't being used for IDR matching.

3. Define survivorship rules
   For each identifier and trait, specify how to determine the "best" value. Common survivorship rules include:

   • Recency: Pick the value most recently seen.
   • Frequency: Pick the value most frequently observed across merged rows.
   • Source priority: Pick the value from the highest-priority source. (For instance, if you trust Salesforce over your app sign-up data for phone numbers, you'd put Salesforce first.)

4. Add additional columns
   Include additional columns if you want to have separate columns for the same identifier type using different logic, e.g. a separate most_recent_email and a most_trusted_email.

5. Save & run
   Click Save to apply your settings. Then click Run to process new or updated rows and generate the Golden Record table.

Once the run completes, you'll have a new table called <output_prefix>_golden_records.

Using the Golden Record table

In Hightouch Customer Studio

If you have Customer Studio, Golden Record automatically creates a schema using the Golden Record configuration and IDR input models:

• Parent model: The Golden Record table is the "parent" model.
• Related models: All IDR input models become "related models," joined by HT_ID.

Hightouch locks certain aspects (for example, the underlying query and the join definitions on HT_ID) so you can't accidentally break your identity graph. However, you can still:

• Rename or alias columns for marketer-friendly naming
• Add descriptions
• Add more related models that aren't part of IDR

Example: If you've defined email in Golden Record using "most recent" logic, that column can be synced to an ESP as the canonical email.

Outside Hightouch

Because <output_prefix>_golden_records lives in your warehouse, you can query it directly for any external reporting or data science workflows. This is especially useful for:

• Analytics dashboards that need a "single source of truth" row per user
• Data science pipelines that require stable, canonical user records linked to as much data about the user as possible

Frequently Asked Questions

1. How is the Golden Record table different from the resolved identifiers table?

<output_prefix>_resolved_identifiers stores all identifier values (for example, multiple emails or phone numbers) as separate rows. <output_prefix>_golden_records stores exactly one "best" (or primary) value per identifier, using your custom survivorship rules. Additionally, the Golden Record table has only 1 unique row per identity where as the <output_prefix>_resolved_identifiers contains 1 unique row per unique identifier values (so multiple rows per identity).

2. Do I need timestamps in my models to use recency-based rules?

Yes, IDR input models require a timestamp in all cases for incremental processing. The same timestamp is used to calculate "most recent" logic.

3. Can I update or delete Golden Record columns later?

Yes. You can revisit the Golden Record tab in your identity graph at any time. Adding or removing a column will trigger IDR to re-materialize <output_prefix>_golden_records on the next run.

4. What field does Golden Record use as the primary key in Customer Studio or when syncing?

By default, we set HT_ID as the primary key for each Golden Record row. In Customer Studio, HT_ID becomes the parent model's primary key. For any external syncs, you can configure how you want to map the HT_ID or other fields as needed.

5. What happens if I disable Golden Record?

If you toggle off Golden Record, Hightouch simply stops updating <output_prefix>_golden_records. The table and associated schema elements remain, but no new data flows in. Re-enabling will refresh it on the next run.

6. What happens when there's a tie between multiple values for a Most Recent or Most Frequent survivorship rule?

When there are multiple different values that are the most recent or most frequent value and the corrresponding rule is used as the survivorship rule, we fall back on the other rule, e.g. for a Most Recent rule, when two values share the same most recent timestamp, we use the value which appears most frequently. If there's a tie on the fallback, we select the value that the warehouse orders first. Since warehouse ordering is usually not guaranteed, the selection in thtis rare case is non-deterministic.

That's it. With Golden Record enabled, you have a clean, single-row-per-customer profile ready for activation, analysis, and beyond. If you run into any issues, reach out to support or your Hightouch representative.