Skip to main content

Description

  • The Conversion Data schema contains one row for each instance of a conversion event tracked in Rockerbox.
  • It includes detailed information about the conversion event including user identifiers, timestamps, order metadata, geographic context, and any other contextual information passed to Rockerbox via conversion event tracking or batch files (flat files).

Schema Structure

  • Conversion data is split into two tables with a 1:1 relationship:
    • log_conversions: Core conversion event data including geographic, device, and revenue information
    • log_conversions_user_identifiers: User identifier and PII data (emails, phone numbers, IP addresses, etc.)
  • Both tables report data for ALL conversion events tracked in Rockerbox (e.g., Purchase, Add to Cart).

Usage Notes

  • Privacy & Compliance: User identifiers and PII are isolated in log_conversions_user_identifiers to enable stricter access controls and comply with privacy regulations.
  • Query Performance: When PII is not needed for analysis, query only log_conversions to reduce data scanned and improve performance
  • Geographic Analysis: Use ip_* fields for geolocation-based analysis depending on conversion IP address; customer-provided fields (city, state, zip) will depend on the user address information provided on the conversion event
  • Revenue Reporting: Use revenue_usd for standardized reporting; original_revenue and original_currency preserve the raw conversion data
  • User Matching: Multiple hash formats (email, phone, IP, address) support identity resolution and audience building while preserving privacy
  • Complete Conversion Record: Join both tables when you need the full context of who converted and the conversion details

Table Creation

These tables are automatically created upon connecting Rockerbox with your supported warehouse provider.

Table Relationship

The two tables have a 1:1 relationship based on the log_conversion_id field:
  • Each record in log_conversions has exactly one corresponding record in log_conversions_user_identifiers
  • Join the tables using: log_conversion_id
  • This separation allows for flexible data governance and access control of personally identifiable information (PII)
Example Join:

Partition Keys

These tables are implemented as external tables. Always leverage partition keys when querying these tables to improve query performance: Log Conversions:
  • log_conversions.conversion_event_id
  • log_conversions.date
Log Conversions User Identifiers:
  • log_conversions_user_identifiers.conversion_event_id
  • log_conversions_user_identifiers.date
Note: The conversion_event_id in these tables references conversion_event_metadata.conversion_event_id. Use conversion_event_metadata to find valid IDs before filtering.

Logical Primary Key

log_conversions

  • log_conversion_id — Unique identifier for each conversion event record

log_conversions_user_identifiers

  • log_conversion_id — Unique identifier matching the corresponding record in log_conversions

Field Reference

Table: log_conversions

Core conversion event data including geographic, device, and revenue information.

Table: log_conversions_user_identifiers

User identifier and personally identifiable information (PII).