Google Analytics and Meta Pixel

How to connect your own GA4 property and Meta pixel to a community or product, exactly which events Insy forwards, and why cookie consent decides whether anything arrives.

Insy can forward a small set of events about your community or product page to your own Google Analytics 4 property and your own Meta pixel. Both integrations are server-to-server: your Measurement ID and Pixel ID are never injected into any page. GA4 is reached through the Measurement Protocol, Meta through the Conversions API, both from Insy’s background worker.

Read the event table before you connect anything. Four internal events are forwarded, they carry a deliberately thin payload, and a visitor who never accepted Insy’s cookie banner produces nothing at all. This page does not cover Insy’s own built-in stats — those are recorded either way and are unaffected by anything here.

Where to connect

Both cards live in the External analytics section of an Integrations page — /managed/<slug>/integrations for a community, /products/<slug>/integrations for a digital product. Each card carries a status badge that reads Inactive until a connection exists and Active afterwards.

An integration belongs to one community or one product, not to your account. The same pixel on three communities means connecting it three times. Each resource holds at most one Google Analytics connection and one Meta connection; re-connecting overwrites the stored credentials in place.

Connecting

What Insy forwards

This is the whole list. Anything not in this table is never sent to your GA4 or your pixel.

Both providers get the same four events under different names. There is no way to add, rename or filter events, and no way to send only purchases.

When each event fires

• view_community — every load of the public community page, once the community data resolves. There is no owner exclusion, so your own visits are counted too.
• view_product — on all three product page routes (the creator-scoped one, the short /p/ one, and a custom domain), once the product resolves. It is suppressed only for platform admins and for a creator previewing an unpublished product; visiting your own published product does count.
• checkout_initiated — for a community, the browser fires it once: on the plan selector opening if the community has more than one plan, or on checkout opening if it has exactly one. The server fires it once more when the embedded checkout session is created. Expect two per buyer, not one.
• checkout_success — the forwarded one is sent server-side, after the payment has been recorded. The thank-you page also fires a checkout_success, but that one carries no community or product ID, so it is dropped before it reaches you and only lands in Insy’s internal stats.

Repeat events with an identical payload are de-duplicated within a single page load, and reset on refresh.

What the payload actually contains

To GA4, one event with:

• client_id, derived from the visitor’s _ga cookie;
• community_id as a parameter;
• page_referrer, utm_source and utm_medium when Insy knows them;
• nothing else — no value, no currency, no items, no product ID.

To Meta, one event with:

• event_name, event_time and action_source: "website";
• user_data containing only fbp and fbc, read from the visitor’s _fbp and _fbc cookies — no hashed email, no IP address, no user agent;
• custom_data with community_id, currency and value;
• event_source_url set to the visitor’s referrer when there is one;
• no event_id.

Server-side only — what a browser pixel would give you and this does not

There is no tag of yours running in the visitor’s browser. Everything is a server call from Insy’s worker, which means:

• no automatic events — GA4’s engagement events and Meta’s automatic page/button events never happen, because your tag is never loaded;
• no audience building or retargeting from your own pixel on Insy pages;
• low Meta match quality — user_data carries cookie identifiers only, with no hashed email;
• no deduplication — no event_id is set, so if you also run a pixel elsewhere, Meta has no way to recognise an Insy event as the same conversion.

Delivery is fire-and-forget. The provider’s response is read and thrown away, nothing is retried, and a rejection from Google or Meta is recorded internally as a successful send. There is no delivery log and no error surfaced in Insy: sent never means accepted.

Cookie consent decides whether anything is sent at all

GA4 forwarding needs the visitor’s _ga cookie; Meta forwarding needs _fbp or _fbc. Those cookies are set by Insy’s own Google and Meta tags, which load only after a visitor presses Accept on Insy’s cookie banner. With no cookie, the event is written to Insy’s internal stats and the external hop is skipped silently.

For a purchase the cookies are frozen onto the checkout reservation when checkout starts, and replayed when the payment lands. If they were empty at checkout, they are still empty at payment.

The “Test analytics” button

Test analytics sits in the header of the External analytics section, above both cards. It is not a Meta-only button: one press fans the event out to every integration on that community or product, so a connected GA4 and a connected pixel are both hit.

The dialog has two inputs: an Event type choice of Page view or Checkout success, and an optional Test code, described as an optional code from Meta Events Manager to verify event delivery. That code is passed straight through as Meta’s test_event_code; GA4 ignores it.

• Page view sends view_community for a community or view_product for a digital product, which arrive as page_view and PageView.
• Checkout success sends checkout_success, which arrives as purchase and Purchase.

Known limits

• There is no disconnect. Neither the interface nor the API can remove an integration. The card’s only button is Connect, which reopens the same dialog and overwrites the credentials. To stop the flow, revoke the API secret or access token on the provider’s side.
• Credentials are stored unencrypted and are returned in full by the endpoint that lists a resource’s integrations, to anyone who can manage that community or product. Treat the GA4 API secret and the Meta access token as shared with every administrator of that resource.
• These endpoints are not part of the public API. They are absent from the public OpenAPI spec and are not a supported integration surface.

When nothing shows up

Next