Introduction

To get the most accurate and actionable insights, we need clean, complete, and properly formatted data. This guide explains how to share your data with us, including the formats we can accept, the fields we require, and examples of what good data looks like.

Following these guidelines helps us process your data faster, avoid delays, and ensure the analysis reflects your business accurately. Think of it as setting the foundation— the better the input, the stronger and more reliable the results we can deliver.

Data Warehouses Instructions

• Snowflake

• GCP BigQuery

• AWS Redshift

• AWS S3

• Databricks

Special Cases

Hierarchical vs. Non-Hierarchical Models

We build non-hierarchical models for most of our customers — i.e. models where the data used is aggregated across geographical regions. For some customers, however, we are building a hierarchical model. In these cases, all of the data (input and target metrics) are broken out by geographical region.

• This document explains what your data should look like for a non-hierarchical model. It can be adapted for hierarchical models by adding a “region” column to each table in your dataset. This column is required and is added to the uniqueness dimensions — for example, if a dataset is unique by (date, campaign_name) in a non-hierarchical model, it will be unique by (region, date, campaign_name) in a hierarchical model.

• For hierarchical models, when possible you should use the same regions in your dataset as you intend to use for your model. In rare cases this won’t be the case — for example, your data might have 100 regions, but we are modeling only 5 (macro) geographical regions. In these cases, you should provide a simple mapping table that associates the regions from the data with the macro regions to be used for modeling. It should meet the following schema:

  Unique by: N/A

  macro_region	region
  NAMER	US
  NAMER	MX
  NAMER	CA
  EMEA	GB
  …	…

Single vs. Multiple Products / SKUs

• In most cases, Paramark builds one or more models for a single product for a customer. For example, we might be building two models on the same dataset, only with different target metrics. The schemas mentioned in this document are written for this use case and can be used as is.

• Sometimes, however, we are building different models for different products. For example, you might have two lines of business with different marketing campaigns and business metrics. For these cases, you have two options:

  • (preferred) provide two different datasets, one per product. In this case, you don’t need to make any changes to the schemas documented here.

  • (also supported) adapt the schemas in this document by adding a “product” column to each table in your dataset. This column is also added to the uniqueness dimensions — for example, data that is unique by (date, campaign_name) in a single-product case becomes unique by (product, date, campaign_name).

Combining marketing channels / business KPIs

• In Supported Data Schemas, we assume that each marketing channel or business KPI will have its own data source. Most of our customers choose this option.

• If you prefer, you can also combine multiple marketing channels or business KPIs into a single data source. To do this, you make two changes to the documented schema:

  • add a column for marketing channel or business KPI

  • add that column to the "unique by" list

• For example, here's what the "Account level with Spend" schema looks like when we combine multiple marketing channels into a single data source:

Unique by: date, channel_name

Data Requirements

General Requirements

Examples of common mistakes:

Example: Columns in English

❌ Incorrect:

✅ Correct:

Example: Include only columns Paramark will use

❌ Incorrect:

✅ Correct:

✅ Correct (campaign data):

✅ Correct (Google data):

Example: Data should be denormalized and no filtering/joins required

❌ Incorrect:

✅ Correct:

Example: Show final computed metric, not component metrics

❌ Incorrect (for a target metric of total signups):

✅ Correct:

Example: One row per day not per transaction

❌ Incorrect (e.g., marketing emails):

✅ Correct:

• Data for a given metric, for a given day, should not be duplicated across data sources. This means:

  ❌ Incorrect

  • Webinars registrations data for 2025-01-01 is in both a Snowflake table and a CSV file.

  ✅ Correct:

  • Webinars registrations data for 2024 is in a Snowflake table, while Webinars registrations data for 2025 is in a CSV file.

Supported Data Schemas

Your data must conform to one of the following schemas, depending on type, granularity, and aggregation level.

Note: We generally use impressions as the input metric for your marketing channels. If your marketing channel does not have impressions, consult with your Growth Advisor to find a suitable alternative.

1. Daily aggregate time series data

Use when you have daily data points for a marketing channel or a company key metrics.

A. Account level data with spend

Commonly used for paid ads when the data is not broken out by campaign.

B. Account level data without spend

Used for organic channels like SEO and organic social.

Unique by: date

C. Business KPIs / Target metrics

Used for business KPIs like sign-ups, purchases, app installs, leads submitted, etc. Provide a region dimension for this data (5. Geography-level data) as that will enable experimentation. If geo data is not available, please work with your Growth advisor on steps to capture that data going forward to enable experimentation.

Unique by: (region, date)

2. Daily campaign-level time series data

Use this to share ad data broken out by campaign or a similar dimension. Feel free to include additional dimensions that may be useful for grouping your data into sub-channels (e.g. advertising channel type for Google or publisher platform for Meta).

Facebook example

Unique by: (date, campaign_name)

Google Search example

Unique by: (date, channel_type, campaign_name)

3. Monthly aggregate time series data

This resembles daily aggregate time series data, only with one row per month rather than one row per day. The date column should reference the first day of the relevant month.

We show an example of a channel with registrations and spend, like Events, but you can include whatever metrics you’d like for modeling.

Unique by: month_start_date

4. Time Window Data (aggregated periods)

Use this when you have summary data over a longer time period, but you don’t have specific daily values. This is common with data sources like out of home and linear TV.

A. Total Numbers Over a Period

In this example, total_impressions and total_spend represent the sum total of all impressions and spend within the time period.

Unique by: n/a

B. Daily Averages Within a Time Window

In this example, daily_impressions and daily_spend represent the assumed impressions and spend for each individual day within the time period.

Unique by: n/a

5. Geography-level data

When sharing data broken out by geographical region, each region should have complete data coverage for the time period (i.e. each date in the dataset should have data for every region). You’ll want to use this format when sharing business KPI data in a format amenable to experimentation.

The examples show daily time series data for the entire year of 2025 for both US and CA regions. The first example is for a marketing channel, and the second example is for a business KPI.

If Paramark is building a hierarchical model, the locations referenced by the “region” column should usually match the regions in your model. If you have multiple sub-regions within each region being used for a hierarchical model, please share the mapping of region and sub-region with us separately. See Hierarchical vs non-hierarchical models for more information.

Marketing channel example

Unique by: (region, date)

Business KPI / target metric example

Unique by: (region, date)

6. Media or post-level data

For some channels, you will have data about the total impressions or views a particular piece of media received, but you don’t have data for the specific number of impressions received on a specific date. For example, on Instagram Organic, you might know that a post created on 2025-01-01 received 100,000 impressions, but you won’t know how many of those impressions happened on that day compared to the following days. For this case we support media-level data formatted in a similar fashion as daily aggregate time series data:

Unique by: URL

Data Types

Date

• Must have year, month, and day

• Must not contain time or timezone information

• Must use a single consistent format within a table or file

• For monthly data, use the first of the month (e.g. “2025-05-01” meaning “the entire month of May”)

Acceptable date formats:

• yyyy-mm-dd (e.g., 2025-01-15)

• yyyy/mm/dd (e.g., 2025/01/15)

• dd-mm-yyyy (e.g., 15-01-2025)

• dd/mm/yyyy (e.g., 15/01/2025)

• mm-dd-yyyy (e.g., 01-15-2025)

• mm/dd/yyyy (e.g., 01/15/2025)

Impressions and Key Metrics

• Must be positive numbers

• Must not contain thousand separators

• May use . (period) as decimal separator if needed

Spend

• Must not include currency symbols or codes

• Must use the same currency across all data sources

• Must be a positive number

• Must not include thousand separators

• May use . (period) as decimal separator if needed

Campaign Name

• Must be text

Region / location

• Must be the code or name of the country, state, region, or city but need not conform to a specific naming scheme like ISO-3166.

• Must use a consistent format throughout (e.g., US, USA, or United States).

• Must be machine-generated (not free text entered by users).

• Should usually match the regions in your model. See Hierarchical vs non-hierarchical models for more information.

Want to learn more about sharing your data? Check out other Paramark data sharing articles here