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:

In this screenshot, we are renaming the Purchase event to EventLookup01 to avoid sending the purchase info to Google. We are also redacting the IP address and hashing the visitors email.

---

Mapping Configuration Overview

Ours supports two types of mappings:

1. Default Mapping Configuration: Predefined mappings that you can customize - applies to all events dispatched by this destination.
2. Event Specific Mapping Configuration: Custom overrides set for individual events

Mappings are configured through the Mappings tab in the destination settings.

How to Configure Mappings

1. Go to the Mappings tab for a destination in the Ours dashboard.
2. Review the Variable Dictionary for various variables you can apply to a mapping
3. 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:

• Explore the Destination Overview.
• Learn how to Track Events.
• Debug mappings using the Recent Events Dashboard.