ActiveCampaign and Stripe: which campaigns preceded an actual payment

It is the second week of the quarter and two people are looking at two screens in the same meeting.

Priya runs lifecycle marketing. Her screen is ActiveCampaign, Campaign Performance, filtered to the last 90 days. Fourteen campaigns. The best one has a 61% open rate and 3,140 clicks. An automation called "Trial day 3 to day 21" has moved 480 contacts through it, and 96 of them hit the goal step.

Marcus runs finance. His screen is the Stripe dashboard, Payments, same 90 days. 212 successful charges. $186,400 collected. An MRR chart that ticks up in three visible steps.

The CEO asks one question: of the money that came in last quarter, how much of it had a campaign in front of it, and which campaigns were they?

Priya can tell you which emails performed. Marcus can tell you which payments cleared. Neither list has a row in common with the other, and the meeting ends the way it always ends, with somebody saying they will pull it together in a spreadsheet.

What ActiveCampaign shows on its own

ActiveCampaign is genuinely strong at the half it owns. You get sends, opens, clicks, bounces and unsubscribes per campaign. You get automation reports showing how many contacts entered each step and where they dropped. You get site tracking if the script is installed, so you can see which pages a known contact visited. You get deals, tags, contact scores and the whole CRM side. On the higher plans you get attribution reporting, and there is an official ActiveCampaign Stripe integration, so revenue events can be pushed onto the contact record and reported against a touch.

That is real revenue attribution and it works. Where it stops is not a bug, it is a boundary. Everything ActiveCampaign reports is anchored to an ActiveCampaign contact, keyed by email address. If the person who paid is not a contact in the list, the payment is invisible. If the payment came from accounts@ while every campaign went to the ops lead who forwarded it, the two never meet. If the charge was an automatic renewal that nobody was marketed to, ActiveCampaign's model may still hand credit to whatever email happened to land that week. And the attribution windows and models are the ones the report offers, not the ones your specific sales motion needs.

What Stripe shows on its own

Stripe knows the money exactly. Charges, refunds, disputes, invoices, subscriptions, proration lines, MRR and churn, customer lifetime. With Sigma you can write SQL directly over all of it. With Data Pipeline you can sync it to a warehouse. If your checkout code sets metadata or client_reference_id, whatever string you passed is sitting right there on the session.

Where Stripe stops is the moment before the payment. Stripe sees a customer arriving at a checkout page already decided. It does not see the eight emails, the webinar registration, the two-week silence, or the reply that said "send me an invoice and I will get it through procurement." If you captured a UTM in metadata you have one string, usually representing the last click that touched the checkout page, for the subset of sessions where your code happened to set it. That is a fragment of a sequence, not the sequence.

Why the gap exists structurally

Look at what each half of the evidence physically is.

The Stripe half is a record. A charge object has an id, a timestamp, an amount, a currency, a status and a customer. It is structured, immutable and machine-readable by design.

The ActiveCampaign half is partly a record and partly a sentence somebody wrote. "Email sent 09:14, opened 09:31, link 2 clicked 09:33" is a record. But the thing that actually explains the deal is usually text: the reply that came back to the campaign, the note a rep typed on the deal, the Slack thread where someone said "this one came from the webinar, not the newsletter", the support ticket where the buyer asked about annual billing.

This is why connecting ActiveCampaign and Stripe is not a reporting feature either product forgot to ship. ActiveCampaign's job ends at the edge of its contact record. Stripe's job ends at the edge of the charge object. Both products are complete. The evidence just sits on both sides of a line neither one is designed to cross.

The usual tools do not close it either, and it is worth being precise about why.

Zapier and Make will absolutely connect ActiveCampaign and Stripe, and they do it well. Write the payment back as a tag, create a deal, update a custom field. But automation platforms are trigger based. They fire when something happens and push a record forward. That shape is excellent for keeping two systems in sync going forward, and it is the wrong shape for a retrospective question. "Which campaigns preceded the payments we took last quarter" is not an event to react to. It is a read across a body of history that already happened.

BI tools have the opposite limitation. Looker, Power BI and Metabase will happily join a Stripe warehouse sync to an ActiveCampaign export and chart the result, and modern conversational layers on top of them will let you ask for that chart in plain English. The constraint is upstream of the interface: they connect to databases and modelled sources. The email reply that says "we are not the buyer, forwarding this on" was never loaded into the warehouse and is not in the semantic model. It is not that the BI tool answers it badly. It is outside what the BI tool can see at all.

What the join actually requires

Two things, and only one of them is mechanical.

The key. Email address is the only identifier both systems reliably hold: customer.email on the Stripe side, contact email on the ActiveCampaign side. That gets you most of the way. Two things make it much better. First, email domain as a fallback key, so accounts@northfield.co can be matched to the campaign that went to dana@northfield.co. Second, client_reference_id on the Stripe Checkout Session. If you are already passing something there, pass the ActiveCampaign contact id, and a whole class of ambiguity disappears at the source.

The judgement. Matching email to email is a lookup. Deciding whether a campaign preceded a payment in any meaningful sense is a reading task, and these are the cases where it bites:

That last row is the whole problem in miniature. The buyer who ignores every tracked link and writes back "can you send an invoice" is the best lead in the dataset, and every click-and-open model rates them dead.

How you would answer it with Skopx

Skopx connects to nearly 1,000 SaaS tools plus your databases, so ActiveCampaign and Stripe are both live at once and the question can be asked in one sentence instead of assembled in two exports.

Priya types this into chat:

Take every Stripe payment over $500 in the last 90 days, excluding renewals and anything later refunded. For each one, find the ActiveCampaign contact by email, or by anyone at the same email domain if there is no direct match. Show me the campaigns, automation steps and email replies that came before that customer's first payment. Put the ones where the payer was never emailed by us in a separate list.

The answer comes back with citations. Each attributed payment links to the Stripe charge and to the specific ActiveCampaign campaign, automation step or reply that supports the claim, so Marcus can click through to the source instead of taking a number on faith. The "never emailed" list is usually the most interesting output in the whole run, because it is the revenue marketing has been quietly claiming or quietly missing.

Once the shape of the answer is right, describe it in another sentence and you get a standing console instead of a one-off answer. That is what the Internal Apps feature does: type what you want to see and it builds the console. In this case, a table of first payments for the period, one row per customer, with the campaign sequence that preceded it, the net amount after refunds, a confidence label, and a filter by campaign so Priya can pull the view for any single send. Alongside it, the unattributed bucket with the domain of each payer. Every figure clicks through to Stripe or ActiveCampaign.

The console reads. The one thing it writes is a button: apply an attributed:<campaign> tag to the matched ActiveCampaign contact, and you click it, one confirmation, per row. Nothing runs on a schedule. Nothing is stored on our side. There is no form, no alert and no public link. It is a window onto live data with one deliberate action attached.

Honest limits

This is not an attribution model. There is no multi-touch weighting, no time decay curve, no incrementality test. It tells you what preceded a payment and shows you the evidence. Whether the campaign caused the payment is still your call, and a sequence being present is not proof.

The email join fails cleanly but it does fail. A payer with no contact record and no domain overlap will land in the unattributed bucket, and that bucket will always contain some genuinely attributable revenue you cannot see from these two systems alone.

Because nothing is stored, rerunning next month rereads live data. If a refund lands or a contact is merged, the number moves. That is correct behaviour, and it means the output is a working view rather than a system of record. Do not paste it into a board deck without a human reading the unattributed list first.

It also does not fix your data. If checkout never captured a reference id and half your contacts have personal Gmail addresses on file, the read gets harder, and no amount of asking nicely in chat changes that.

Skopx is $16 per seat per month on Team, which includes 2.3 million AI tokens per seat, and $5 for Solo. SOC 2 controls are in place. If you want to try the question above against your own ActiveCampaign and Stripe accounts, it takes about as long to ask as it took to read this paragraph.