Data Mapping

Ours allows you to map internal event data to a destination schema, providing flexibility in how events and their associated properties are transformed and sent to your configured destinations. Whether you want to rename events, hash visitor data, or customize property handling, data mapping enables full control over your data pipeline.

---

Renaming Events

One of the key features of data mapping is the ability to rename events before they are sent to a destination. This is particularly useful for:

• Aligning event names with the schema requirements of specific destinations.
• Obfuscating sensitive event names to enhance privacy.

Example

This mapping sends appointment requests to an analytics destination as Appointment Booked, retains the service line, and hashes the visitor email before dispatch.

---

Mapping Configuration Overview

Ours supports two types of mappings:

1. Default Mapping: The baseline fields and transformations that apply to every event dispatched by this destination.
2. Custom Mappings: Per-event overrides for events that need different fields or transformations.

Use the Default Mapping tab to set the shared baseline, then use Custom Mappings when an individual event needs an override.

How to Configure Mappings

1. Go to the Mappings tab for a destination in the Ours dashboard.
2. Open Default Mapping to configure fields that apply to every event, or Custom Mappings to configure an individual event.
3. Review the Variable Dictionary for variables you can apply to a mapping.
4. Use the dropdown menus to:
   • Map internal properties to destination fields.
   • Apply modifications (e.g., Hash, DomainOnly).

---

Modifications

Ours provides several modification types to transform data before sending it to destinations. There are many modifications. A partial list includes:

---

Custom Salting

Custom salting allows you to configure a unique salt value for each destination, enhancing the security of hashed data. When a custom salt is configured for a destination, any hashing performed within that destination will incorporate your custom salt, making the hashed output unique and significantly harder to reverse.

How Custom Salting Works

When you configure a custom salt for a destination:

• All hashing operations within that destination will use your custom salt value.
• The same input data (e.g**., **an email address) will produce a different hash when combined with your custom salt compared to standard hashing.
• Each destination can have its own unique salt, providing isolation between different data flows.

Benefits and Tradeoffs

Custom salting provides several security and privacy advantages, but also comes with important tradeoffs to consider:

Benefits:

• Enhanced Security: By making each hash unique to your salt, custom salting significantly increases the difficulty of brute-force attacks and makes pre-computed lookup tables (rainbow tables) ineffective.
• Prevents Cross-Customer Correlation: Since identical inputs produce different hashed outputs when different salts are used, custom salting prevents data correlation across different customers or datasets.
• Regulatory Alignment: Properly salted and hashed data may help meet certain regulatory requirements. For example, HHS OCR guidance indicates that properly salted and hashed Protected Health Information (PHI) may be considered de-identified.

Tradeoffs:

• Cross-Platform Matching: Customer-specific salts will disrupt the ability to match data across different platforms or datasets that do not share the same salt.
• Attribution Impact: The disruption in cross-platform matching may reduce ad attribution efficiency, as it becomes more difficult to track user journeys across various touchpoints. This is a direct consequence of the increased privacy protection offered by custom salting.

Configuring Custom Salts

Custom salts are configured per destination in the destination settings. By default, destinations do not use custom salts. You can generate and manage custom salts for each destination as needed.

---

$ignore Directive

Use the $ignore directive to exclude a property from the final output. This ensures that unnecessary or sensitive data is not sent to destinations.

Example:

To exclude the user.phone_number field, set its map to $ignore.

---

Best Practices for Data Mapping

1. Rename Sensitive Events:
   • Use generic event names to maintain privacy while ensuring compatibility with destinations.
2. Hash or Redact Sensitive Properties:
   • Protect visitor data like email, phone_number, or IP address by applying Hash or Redacted modifications.
   • Consider configuring custom salting for destinations that handle sensitive data to enhance security and prevent cross-customer correlation.
3. Test Custom Mappings:
   • Verify that your mappings are working correctly by reviewing data in the Recent Events Dashboard.
4. Avoid Unused Mappings:
   • Use the $ignore directive to exclude unnecessary properties from being sent.

---

Summary

Data mapping in Ours provides powerful tools to transform and customize your event data for any destination. By leveraging default mappings, visitor overrides, and modifications, you can ensure data is accurately sent while maintaining privacy and compliance.

To get started:

• Review the Destination Overview.
• Combine, reformat, and conditionally map values with Mapping Templates.
• Learn how to Track Events.
• Debug mappings using the Recent Events Dashboard.