Appsflyer to Snowflake: How to Move Your Data

Moving AppsFlyer into Snowflake puts mobile attribution beside the revenue and retention data that decides whether a channel was worth buying. It also puts device-level records about identifiable people into a warehouse a lot of colleagues can query, which is the part worth planning for.

This guide covers the managed path with Airbyte. Two things shape the build: raw data is more personal than most marketing datasets, and Snowflake gives you column and row level controls that are worth applying before anybody is granted access.

Appsflyer to Snowflake at a glance:

Why move data from Appsflyer to Snowflake?

Two situations account for most of these pipelines.

The first is return on ad spend calculated properly. Attribution tells you a channel produced installs, and whether those installs were worth their cost needs revenue, retention and support data AppsFlyer has never seen. That join happens in a warehouse or it does not happen.

The second is governance, since Snowflake's access controls suit a dataset this sensitive better than most destinations do. If your priority is instead keeping several years of granular rows as cheaply as possible, a lakehouse has no volume ceiling and AppsFlyer to Databricks is the more economical home.

What do you need before you start?

Four things, and the last one is a conversation rather than a configuration:

Confirmation that your subscription includes raw data. Raw data reports are a premium AppsFlyer capability rather than something every account has, and aggregate reports are a separate permission. The AppsFlyer source documentation lists the streams and fields.

An API token, your app identifier and timezone. Only an account admin can create the token, and AppsFlyer reissues it when that admin changes. One source covers one app, and the timezone setting should match your app settings or daily figures shift.

Snowflake objects and a role that can create tables. Give this its own schema rather than dropping it beside general reporting tables, because the access controls it needs are not the ones your other data needs.

Agreement on who may read device-level records. Most marketing analysis needs counts rather than identifiers, and deciding that before the schema is handed out is far easier than retrofitting controls to tables people already query.

If your Snowflake account restricts inbound traffic by IP, add the Airbyte Cloud IP addresses to the network policy before you begin.

How do you build an Appsflyer to Snowflake pipeline in Airbyte?

Step 1: Inventory the identifiers before anybody gets access

Look at the fields the raw streams carry and mark the ones that identify a person or a device. That list is what your masking policies will cover, and building it before the first sync means the controls exist from the moment data lands rather than being added after somebody has already browsed the table. It is twenty minutes of work and the only version of this that is genuinely cheap.

Step 2: Configure the AppsFlyer source

Click Sources in the left navigation, then New Source, and select AppsFlyer, following adding a source. Supply the API token, app identifier, start date and timezone. Remember that a start date earlier than ninety days ago is capped silently rather than rejected, so do not assume a long backfill succeeded because nothing complained.

Step 3: Configure the Snowflake destination

Click Destinations, then New Destination, and select Snowflake, following adding a destination. Supply the account identifier, warehouse, database, schema and role. Keep this in a schema of its own so the policies you are about to apply do not have to be reasoned about alongside everybody else's tables.

Step 4: Create the connection, then apply the policies

Click Connections, then New connection, select your streams and a sync mode. Then apply masking and row access policies before telling anybody the schema exists. The window between data landing and controls being applied is the window in which somebody reads something they should not, and it is entirely avoidable.

Keep the schedule tight, because raw history reaches back only ninety days and anything older exists in Snowflake and nowhere else.

What is actually in the raw data?

Records about individual devices and the people using them. Raw install and event reports carry device identifiers, network details and the attribution chain that led to an install, which is considerably more personal than the campaign-level figures most marketing pipelines deliver. It is the reason raw data is a premium capability rather than a default.

That changes what landing it in a warehouse means. In AppsFlyer, reaching this data requires a login and a role. In Snowflake it becomes ordinary columns that any analyst with access to the schema can select, and the exposure has changed completely even though the data has not. Nobody intends that; it simply follows from loading the tables and moving on.

Worth remembering too that the aggregate report streams exist alongside the raw ones and carry none of this. If the analysis you actually need is channel performance rather than device-level attribution, taking aggregates instead removes the governance problem entirely rather than managing it, which is the cheapest solution available and the one people forget to consider.

How should Snowflake hold device-level attribution?

Behind masking policies applied at the column level, which is the tool that fits this problem precisely. Almost all marketing analysis counts installs, compares channels and measures retention, and none of that requires reading a device identifier. A masking policy lets the same table serve an analyst who sees nothing identifying and a fraud investigator who sees everything.

Row access policies handle the other dimension. Where you run several apps or operate across markets with different obligations, restricting a role to particular apps or regions is straightforward here and awkward almost everywhere else. For an organisation whose European data is governed differently from the rest, that distinction is worth having in the platform rather than in a document nobody reads.

Add a retention decision to that, because the source keeps ninety days and your warehouse keeps whatever you let it. Holding device-level records indefinitely by default is the kind of thing that surfaces awkwardly during a deletion request, so agree a period and implement it. And use TRY_CAST when reading anything typed loosely from these streams, since a plain cast will stop a query dead on one unexpected value rather than returning null and letting you find it.

Frequently asked questions

Do I need raw data for this to be useful?

Often not. Aggregate report streams answer channel performance questions without device-level records, which removes the governance burden rather than requiring you to manage it.

Can analysts work without seeing identifiers?

Yes, and that is what column-level masking is for. Counting, comparing and measuring retention need no identifying values, so mask them and grant the real values only to roles that genuinely need them.

Why does my backfill start later than I asked?

AppsFlyer serves raw reports for the most recent ninety days and an older start date is capped silently. Beyond that window your warehouse tables are the only copy.

Our sync stopped after a staff change.

The token is tied to the account admin who created it, and AppsFlyer issues a new one when that admin changes. Update the configuration with the reissued token.

Can I do this without writing code?

The pipeline, yes. Masking and row access policies are SQL, and with device-level data they are not an optional refinement.

Get your Appsflyer data into Snowflake

Ask first whether you need raw data at all, since aggregate streams answer many questions without device-level records. If you do, inventory the identifying fields before the first sync and apply masking and row access policies before anybody is told the schema exists. Set the timezone to match your app, expect the ninety-day cap to apply silently, and agree how long you will keep records the source itself discards.

Airbyte's connector catalog includes 600+ pre-built connectors, so attribution can sit beside the revenue that justifies it. For the same source into another warehouse, see AppsFlyer to BigQuery, and for paid social performance into the same destination, Facebook Ads to Snowflake.

Start syncing now →