Landingi With Causality Engine: Keep the Ad's Credit Past the Page

The short answer: a Landingi page can score a strong conversion rate while the store's GA4 files the same buyers under Referral, credited to the page's own domain instead of the ad that paid for the visit. Landingi, the landing page platform with the Lunar AI generator, counts a form submission as a page's conversion by default and can count a button click instead, per its conversion goal article; its visits rest on a cookie that lasts 30 minutes (stat system). None of that is the order. Carry the ad's UTM tags through the page to the store, and the GA4 export becomes something Causality Engine, a causal attribution tool that reads that export, can use. The first finding on the start page costs nothing.

Disclosure: I founded Causality Engine and own it, and this page recommends it. Every claim about it links to Causality Engine's own pages.

What to check, in this order:

1. Handoffs against arrivals. For example, 1,646 tracked button clicks on the page and 1,509 store sessions from that campaign in GA4 means 1,646 - 1,509 = 137 visitors lost between the two. A small gap is consent and ad blockers. A large one is a broken link.
2. The script Landingi already gives you. Its UTM pass-through guide copies the page's URL parameters onto redirect buttons.
3. The Referral row in GA4. If your page's domain appears there with purchases next to it, the ad has lost credit for those orders.

How a page in the middle changes the channel

Picture the path. A Meta ad sends a visitor to a Landingi page tagged utm_source=facebook&utm_medium=paid_social. Google's default channel group files that as Paid Social, since the source is a social site and the medium starts with "paid". The visitor clicks through to the store on another domain.

What GA4 records at the store depends on that second click. If the link carries no tags and GA4 on the two domains is not joined, the store session starts with the page as its referrer, and Google's channel rules describe Referral as arrivals through non-ad links on other sites (default channel group). Google's cross-domain measurement page explains the other half: without it, each domain sets its own cookies, so one person counts as two users with two sessions.

Three fixes, each documented:

• Pass the tags along. Landingi's guide has you set the button to Redirect, tick Create a lead after a click, and add a short script under the page's JavaScript Code tab at Body bottom. The script appends every parameter in the page URL to the button's target, and adds a _session parameter for EventTracker (UTM pass-through guide).
• Join the domains. Put the same Google tag on page and store, and list both under Configure your domains, so the IDs travel in a _gl parameter (cross-domain measurement).
• Use a subdomain. Google's unwanted referrals page says a referrer on the same domain as the page, or any of its subdomains, is not treated as a referral.

Landingi's own GA4 setup is a Google tag pasted under JavaScript Code in the Head position, with Form interactions left on so form submits reach GA4 (GA4 guide); EventTracker can also send its events, through one connection per account (EventTracker GA4).

What Landingi counts as a conversion

• By default, a form submission. Each page's statistics count leads from forms (conversion goal article).
• Optionally, a click. Create a lead after a click turns a redirect button into a conversion. With both a form and a tracked button on a page, the two are summed.
• Sales, where Landingi took the payment. The stat system article lets you switch the goal to sales closed through Stripe, PayPal or PayU, or to an event once EventTracker is on.
• Visits by cookie. A visit is one ls_sid cookie, valid for 30 minutes, so a return within half an hour is not a new visit. Landingi's visits article explains why this differs from GA4's sessions and users.

A purchase in a separate store is invisible to all four.

Landingi and the read, at a glance

Worked example: the Referral row that belonged to Meta

For example, with invented figures that describe no real store: in March, one Meta campaign sends traffic to a Landingi page with a single button to a product page. The store books 1,212 orders that month from all channels.

• Landingi, goal set to clicks: 7,840 visits and 1,646 conversions, a rate of 1,646 ÷ 7,840 = 21%.
• Meta Ads Manager credits the campaign with 171 purchases.
• GA4, before any fix: 1,509 store sessions referred by the page's domain, with 88 purchases under Referral; 19 more purchases under Paid Social, from buyers who came back through a later ad.

GA4 links 88 + 19 = 107 purchases to this campaign in some row, but only 19 under the channel that paid for them. Meta's 171 is 171 - 107 = 64 above even that combined figure, which is normal for a platform counting by its own rules.

Read that export as it stands and Referral earns credit that belongs to Paid Social. The model can only weigh the channels the file names. Per the how-it-works page, it reports each channel's caused share against a last-click rebuild, with a data-health score from 0 to 100 and a next step. Fix the handoff first, collect clean months, then read. If Paid Social's caused share still sits far below Meta's claim, cut or raise spend in one region before the whole account.

A free check that needs no read

This one is by hand, and it settles whether the export is usable. Set the page's goal to clicks, add the pass-through script, then put a test URL with made-up tags through the page and read the store's address bar. Over the next 7 days, compare Landingi's click conversions with GA4's store sessions carrying the campaign's source and medium.

For example, 410 clicks against 388 tagged sessions is 388 ÷ 410 = 95% arriving with their source intact. If the page's domain still shows up in Referral with purchases, the hand-off is leaking credit, and no attribution method can repair it afterwards.

Landingi's A/B tests answer another question: they compare page variants by leads, recommend several hundred conversions on each, and leave the winner to you. They do not hold back a channel.

Limits of the pairing

• Needs a purchase key event and history. The one-off read page takes key events from GA4's Advertising tab; the how-it-works page asks for 12 months or more.
• Sees channels, not pages. A Landingi variant, a section or a button is below what the read reports.
• Declines thin data. A channel under 1% of credit on both methods is called too small to act on (how it works).

Landingi's conversion rate counts the click that leaves the page, and both the A/B test and the page's Overview panel work from that number, so a page that sends more people to the store looks better whether or not they pay. The order count lives in the store.

When the handoff holds, export the Attribution paths CSV and drop it on the start page for a free first finding worked out in your browser. Causality Engine, which I founded, charges €99 once for the full read, with a refund inside 30 days (pricing, checked on 11 November 2026).

See also

• Landingi: Lunar, visit caps and credits
• How to use Landingi: a campaign page with an A/B test
• Landingi on the marketplace: Landingi's affiliate program terms
• Causality Engine: the read and where it declines
• How to use Causality Engine: the steps from file to decision
• Causality Engine on the marketplace: its affiliate terms, from the owner
• Landingi vs Unbounce: click data or traffic routing
• How to test landing page variants with a holdout: variant tests with a control

FAQ

Does Landingi pass anything to Causality Engine?

No, and it has no reason to. The two never connect. Causality Engine reads channels from a GA4 export (integrations page), so Landingi matters to it only through the tags and sessions GA4 records at the store.

Should I tag the button with my own UTMs instead?

Not if you want the ad credited. A fresh utm_source on the button names the page as the source in GA4. Copying the incoming tags, as Landingi's pass-through guide does, keeps the original one.

Why do Landingi's visits and GA4's sessions differ?

They count differently. Landingi counts one ls_sid cookie per 30 minutes, while GA4 builds sessions and users by its own rules, as Landingi's visits article sets out.