LinkedIn Ads to Amazon Redshift: How to Move Your Data

Moving LinkedIn Ads into Amazon Redshift matters more than for most advertising platforms, because B2B sales cycles outlast attribution windows. A click in March becomes an opportunity in June and a closed deal in September, and no advertising platform can see that far on its own.

Two things shape this build. The analytics streams are not eleven datasets but the same spend sliced eleven ways, and Redshift cannot be loaded without a staging bucket, which adds an AWS prerequisite to an advertising pipeline.

LinkedIn Ads to Amazon Redshift at a glance:

Why move data from LinkedIn Ads to Amazon Redshift?

Two situations account for most of these pipelines.

The first is attribution across a long sales cycle. LinkedIn reports the conversions it can see, which on a B2B purchase is a fraction of the story, and joining spend to your CRM is the only way to know which campaigns produced revenue rather than form fills.

The second is comparing channels inside an AWS estate. If your warehouse, your CRM extract and your other advertising sources already live there, bringing LinkedIn across lets you test its audience quality claim rather than taking it on trust.

What do you need before you start?

The stream decision is worth thinking about, and the bucket is a prerequisite you cannot skip:

Authentication with the ads reporting scope. Authenticate directly on Airbyte Cloud, or supply credentials from a LinkedIn developer application on self-managed deployments. The application needs the scope for reading ad analytics and reporting data. The LinkedIn Ads source documentation lists the requirements.

A decision about which pivots you actually report on. There are eleven built-in analytics streams, by campaign, creative, impression device and seven member attributes. Selecting all of them is the default mistake, for reasons covered below.

An S3 staging bucket and IAM permissions. The Redshift destination writes data to S3 as files with a manifest, then issues a COPY command, which is Redshift's own recommended approach. You need put, get, delete and list on the bucket, in the same region as the cluster.

A lookback window and Redshift entities. The lookback applies to every incremental stream rather than only the analytics ones. On the warehouse side you need a database, a schema and a user able to write data and manage staging operations.

Note also that an SSH tunnel covers the SQL connection only. Staging traffic reaches S3 over HTTPS regardless, so a network design assuming everything passes through a bastion is wrong.

How do you build a LinkedIn Ads to Amazon Redshift pipeline in Airbyte?

Step 1: Decide what you will actually report on

Ask whoever runs your campaigns which breakdowns they use in practice. Job function and seniority are usually the ones that justify LinkedIn's pricing, while several of the others are interesting once and never again. Every pivot you take costs sync time and storage for the same underlying spend.

Step 2: Configure the LinkedIn Ads source

Click Sources in the left navigation, then New Source, and select LinkedIn Ads, following adding a source. Authenticate, set a start date, optionally limit the sync to specific ad account identifiers, and define any custom reports with their pivot categories and time granularity.

Step 3: Configure the Redshift destination

Click Destinations, then New Destination, and select Redshift, following adding a destination. Supply the cluster host, database, schema and credentials, along with your S3 bucket and IAM key. Staging files are removed after a successful COPY by default, and can be retained if you need them for debugging.

Step 4: Create the connection and set your keys

Click Connections, then New connection, select your streams and an incremental sync mode. Daily suits advertising data. Set sort keys on the report date, because campaign reporting is almost always filtered by period, and expect the initial analytics sync to take considerably longer than you would guess.

Raising the number of workers is the lever if analytics streams are slow, and keeping the connector current helps more than people expect, for reasons covered below.

Why can you not add the analytics streams together?

Because each one is the whole dataset viewed through a different lens. Ad analytics by campaign, by creative, by impression device, by member country, by job function, by seniority and the rest all describe the same spend over the same period, grouped differently.

So summing across them multiplies your reported spend by however many pivots you selected. That is an obvious error stated plainly and a very easy one to make in practice, because the tables sit side by side in the same schema with similar column names and nothing marks them as alternative views of one thing.

Two things help. Name your views so the relationship is obvious to somebody who did not build the pipeline, and prefer a custom report where you need several dimensions at once, since those allow up to three pivot categories in a single stream rather than three tables you then have to avoid combining.

Why do analytics syncs take so long?

Because the connector requests analytics per campaign and per time slice, so the work grows with your campaign count rather than your spend. An account with a thousand campaigns generates a great many requests even when most of those campaigns stopped running a year ago.

Newer connector versions improved this by taking campaign status and schedule into account when generating slices, which avoids querying completed campaigns beyond their end date. Keeping the connector current therefore has a direct effect on sync duration here, more so than on most sources.

That matters on this destination because the time is spent reading from LinkedIn rather than writing to Redshift. Sizing the cluster up will not help, and raising the number of workers, selecting fewer pivots and limiting the ad accounts you sync will.

Frequently asked questions

Can I sum the different ad analytics streams?

No. Each is the same spend pivoted differently, so adding them together multiplies your totals. Pick the pivots you report on and keep them clearly named.

Do I need an S3 bucket to load into Redshift?

Yes. The destination stages data in S3 and loads it with COPY, which is Redshift's recommended approach. Put the bucket in the same region as your cluster.

Why is my incremental sync still slow?

The time is spent reading from LinkedIn rather than writing to Redshift, so a bigger cluster will not help. Update the connector, raise the number of workers, and sync fewer pivots.

Does the lookback window only affect analytics?

No. It applies to every incremental stream, including campaigns, creatives, conversions, account users and any custom reports you define.

Can I do this without writing code?

Yes. The setup above is entirely UI-driven, including custom report definitions. You will want Redshift views joining spend to your CRM, which is where B2B attribution actually happens.

Get your LinkedIn Ads data into Amazon Redshift

Choose your pivots deliberately rather than taking all eleven, and make sure whoever queries the result understands they are alternative views of one spend. Provision the staging bucket in your cluster's region, sort on the report date, and remember that slow syncs are a source problem rather than a cluster one.

Airbyte's connector catalog includes 700+ pre-built connectors, so paid social can sit beside the CRM and revenue data that judges it. For the same source in another warehouse, see LinkedIn Ads to Snowflake, and for paid search alongside it, Google Ads to Snowflake.

Start syncing now →