Klaviyo dbt Package

Unioning Multiple Klaviyo Connections

If you have multiple Klaviyo connections in Fivetran and would like to use this package on all of them simultaneously, we have provided functionality to do so. The package will union all of the data together and pass the unioned table into the transformations. You will be able to see which source it came from in the source_relation column of each model. To use this functionality, you will need to set either (note that you cannot use both) the klaviyo_union_schemas or klaviyo_union_databases variables:

# dbt_project.yml
...
config-version: 2
vars:
  klaviyo:
    klaviyo_union_schemas: ['klaviyo_usa','klaviyo_canada'] # use this if the data is in different schemas/datasets of the same database/project
    klaviyo_union_databases: ['klaviyo_usa','klaviyo_canada'] # use this if the data is in different databases/projects but uses the same schema name

Event Attribution

If available, the package uses Klaviyo's native property_attribution field from the EVENT source for attributing events to campaigns and flows. This approach ensures consistency with Klaviyo's platform and provides the most accurate attribution data.

Primary Attribution Method:

• Uses Klaviyo's built-in property_attribution field when available
• Events inherit attribution from parent events via attributed_event_id references
• Aligns with Klaviyo's internal attribution model
• No additional configuration required

Session-Based Attribution Fallback: For users who need custom attribution logic or are migrating from older package versions, an optional session-based attribution method is available. This method is disabled by default if your EVENT source contains the property_attribution field but can be enabled by setting using_native_attribution: false. If you do not have the property_attribution field, this method will be used by default.

When enabled, this method uses configurable lookback windows:

• 120 hours (5 days) for email events
• 24 hours for SMS events

# dbt_project.yml
vars:
  klaviyo:
    using_native_attribution: false # Disable native attribution to use session-based fallback
    klaviyo__email_attribution_lookback: 120 # Hours for email attribution
    klaviyo__sms_attribution_lookback: 24 # Hours for SMS attribution

Note: For detailed information about attribution methods and when to use each approach, see the DECISIONLOG.md.

Events already associated with campaigns or flows in Klaviyo will never have their source attribution data overwritten by the package modeling.

Attribution-Eligible Event Types (Session-Based Fallback Only)

Note: This configuration only applies when session-based attribution is used. The primary attribution method uses Klaviyo's native attribution without additional filtering.

When using the session-based attribution fallback, the package will only credit email opens, email clicks, and SMS opens with conversions by default. This filter determines which event types can trigger new attribution sessions and is aligned with Klaviyo's internal attribution model.

To customize which events can qualify for attribution in the session-based method, add the following configuration to your dbt_project.yml file:

# dbt_project.yml

...
config-version: 2

vars:
  klaviyo:
    klaviyo__eligible_attribution_events: ['types', 'of', 'events', 'to', 'attribute', 'conversions', 'to'] # this is case-SENSITIVE and should be in all lower-case!!

Filtering Conversion Metrics to Pivot Out

The Klaviyo dbt package pivots relevant conversion events out into metric columns in the klaviyo__person_campaign_flow, klaviyo__campaigns, klaviyo__flows, and klaviyo__persons models. The package will sum up revenue attributed to each person's interactions with flows and campaigns (plus organic actions), count the instances of each kind of triggered conversion, and, at the flow and campaign grain, count the number of unique people who converted. The package splits up events to pivot out into two variables, klaviyo__count_metrics and klaviyo__sum_revenue_metrics, which will record the count of events/users and their associated revenue values, respectively.

By default, the package is configured to pivot out the below metrics. To change the conversion events that are pivoted out, tailor the following configuration to your desired metrics in your dbt_project.yml file:

# dbt_project.yml

...
config-version: 2

vars:
  klaviyo: # case insensitive 
    klaviyo__count_metrics: 
      - 'Active on Site'
      - 'Viewed Product'
      - 'Ordered Product'
      - 'Placed Order'
      - 'Refunded Order'
      - 'Received Email'
      - 'Clicked Email'
      - 'Opened Email'
      - 'Marked Email as Spam'
      - 'Unsubscribed'
      - 'Received SMS'
      - 'Clicked SMS'
      - 'Sent SMS'
      - 'Unsubscribed from SMS'

    klaviyo__sum_revenue_metrics:
      - 'Refunded Order'
      - 'Placed Order'
      - 'Ordered Product'
      - 'checkout started'
      - 'cancelled order'

Passthrough Columns

Additionally, the Klaviyo package includes all source columns defined in the macros folder of the source package. We highly recommend including custom fields in this package as models now only bring in the standard fields for the EVENT and PERSON tables.

You can add more columns using our passthrough column variables. These variables allow for the passthrough fields to be aliased (alias) and casted (transform_sql) if desired, although it is not required. Datatype casting is configured via a SQL snippet within the transform_sql key. You may add the desired SQL snippet while omitting the as field_name part of the casting statement - this will be dealt with by the alias attribute - and your custom passthrough fields will be casted accordingly.

Use the following format for declaring the respective passthrough variables:

# dbt_project.yml

...
vars:
  klaviyo__event_pass_through_columns: 
    - name:           "property_field_id"
      alias:          "new_name_for_this_field_id"
      transform_sql:  "cast(new_name_for_this_field as int64)"
    - name:           "this_other_field"
      transform_sql:  "cast(this_other_field as string)"
  klaviyo__person_pass_through_columns:
    - name:           "custom_crazy_field_name"
      alias:          "normal_field_name"

Changing the Build Schema

By default, this package will build the Klaviyo final models within a schema titled (<target_schema> + _klaviyo), intermediate models in (<target_schema> + _int_klaviyo), and staging models within a schema titled (<target_schema> + _stg_klaviyo) in your target database. If this is not where you would like your modeled Klaviyo data to be written to, add the following configuration to your dbt_project.yml file:

# dbt_project.yml

...
models:
    klaviyo:
      +schema: my_new_schema_name # Leave +schema: blank to use the default target_schema.
      staging:
        +schema: my_new_schema_name # Leave +schema: blank to use the default target_schema.

Note that if your profile does not have permissions to create schemas in your warehouse, you can set each +schema to blank. The package will then write all tables to your pre-existing target schema.

Change the source table references

If an individual source table has a different name than the package expects, add the table name as it appears in your destination to the respective variable:

IMPORTANT: See this project's dbt_project.yml variable declarations to see the expected names.

vars:
    klaviyo_<default_source_table_name>_identifier: your_table_name 

Fivetran offers the ability for you to orchestrate your dbt project through Fivetran Transformations for dbt Core™. Learn how to set up your project for orchestration through Fivetran in our Transformations for dbt Core setup guides.