Klaviyo Transformation dbt Package (Docs)

Unioning Multiple Klaviyo Connectors

If you have multiple Klaviyo connectors 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_source:
    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

Attribution Lookback Window

This package attributes events to campaigns and flows via a last-touch attribution model in line with Klaviyo's internal attribution. This is necessary to perform, as Klaviyo does not automatically send attribution data for certain metrics. Read more about how the package's attribution works here and see the source code here.

By default, the package will use a lookback window of 120 hours (5 days) for email-events and a window of 24 hours for SMS-events. For example, if an 'Ordered Product' conversion is tracked on April 27th, and the customer clicked a campaign email on April 24th, their purchase order event will be attributed with the email they interacted with. If the campaign was sent and opened via SMS instead of email, the 'Ordered Product' conversion would not be attributed to any campaign.

To change either of these lookback windows, add the following configuration to your dbt_project.yml file:

If you would like to disable the package's attribution process completely, set these variables to 0.

# dbt_project.yml

...
config-version: 2

vars:
  klaviyo:
    klaviyo__email_attribution_lookback: x_number_of_hours # default = 120 hours = 5 days. MUST BE INTEGER.
    klaviyo__sms_attribution_lookback: y_number_of_hours # default = 24 hours. MUST BE INTEGER.

Note that 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

By default, this package will only credit email opens, email clicks, and SMS opens with conversions. That is, only flows and campaigns attached to these kinds of events will qualify for attribution in our package. This is aligned with Klaviyo's internal attribution model.

However, this package allows for the customization of which events can qualify for attribution. To expand or otherwise change this filter on attribution, 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 blank for just the target_schema
    intermediate:
      +schema: my_new_schema_name # leave blank for just the target_schema
  klaviyo_source:
    +schema: my_new_schema_name # leave blank for just the 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.