--- title: Google Analytics and Meta Pixel description: 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](/integrations) — `/managed//integrations` for a community, `/products//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 **Google Analytics** 1. **Open the dialog** Press **Connect** on the Google Analytics card. The dialog is titled *Connect with Google Analytics* and has exactly two fields — there is no property picker and no Google sign-in. 2. **Measurement ID** The Measurement ID of the GA4 **data stream** you want the events to land in. Not the property number, not a Google Tag Manager container ID. 3. **API Secret** A **Measurement Protocol API secret** created on that same data stream. It is not an OAuth client, a service-account key or a Google Cloud API key — the Measurement Protocol is the endpoint Insy calls, so only a secret issued for it works. The field is masked. 4. **Save** Insy immediately posts one throwaway event named `creds_validation` to Google's Measurement Protocol **debug** endpoint with both values, and refuses to store the pair if Google complains about `measurement_id` or `api_secret`. The rejection message you see is Google's own text, prefixed with `Invalid GA4 credentials:`. **Meta Pixel** 1. **Open the dialog** Press **Connect** on the Meta Pixel card. The dialog is titled *Connect with Meta Pixel* and has exactly two fields — there is no Facebook login and no Business Manager step. 2. **Pixel ID** The numeric ID of the pixel that should receive the events. 3. **Access Token** A **Conversions API access token** generated for that pixel. Insy calls `graph.facebook.com/v21.0/PIXEL_ID/events`, so a token without Conversions API access to that exact pixel will be refused. The field is masked. 4. **Save** Insy immediately posts a real `PageView` event to your pixel, tagged `test_event_code: TEST00000`, with `client_user_agent: "validation-test"` and `client_ip_address: "0.0.0.0"`. If Meta refuses it, the credentials are not stored and you see Meta's own error text prefixed with `Invalid Meta Pixel credentials:`. > **A rejection shows you two contradictory things at once** > > When Google or Meta rejects the credentials, the dialog closes and the *Google Analytics configured* > / *Meta Pixel configured* toast fires anyway — and at the same time the card itself is replaced by a > red box carrying the provider's own message, prefixed `Invalid GA4 credentials:` or > `Invalid Meta Pixel credentials:`. Nothing was stored. Believe the red box, not the toast: press > **Close** on it to bring the card back, then **Connect** again with corrected values. > **Insy does not check the format of anything you paste** > > Both fields are accepted as any non-empty text. A typo is caught only by the provider's reply during > that save-time round trip, never by Insy. ## What Insy forwards This is the whole list. Anything not in this table is never sent to your GA4 or your pixel. | Insy event | Google Analytics 4 | Meta | | --- | --- | --- | | `view_community` | `page_view` | `PageView` | | `view_product` | `page_view` | `PageView` | | `checkout_initiated` | `begin_checkout` | `InitiateCheckout` | | `checkout_success` | `purchase` | `Purchase` | | `view_profile` | not forwarded | not forwarded | | `explore_page_view` | not forwarded | not forwarded | 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. > **Digital products never send begin_checkout or InitiateCheckout** > > The browser fires `checkout_initiated` for a digital product with a product **variant** ID and a > reservation ID, but no product ID. Insy drops any event carrying neither a community ID nor a > product ID, so the event is stored internally and goes no further. For digital products your funnel > in GA4 and Meta jumps straight from `page_view` to `purchase`. ## 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`. > **Meta receives the amount in minor units** > > `value` is the payment amount in cents, sent without dividing. A **99.00 PLN** sale reaches your > pixel as `value: "9900"` with `currency: "PLN"` — a hundred times the real figure. Any ROAS or > value-based optimisation built on it is wrong by that factor. GA4, by contrast, receives no revenue > at all: its `purchase` event arrives with no value and no currency. ## 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. > **The banner is not shown on the pages that sell** > > Insy suppresses the cookie banner on community pages, product pages and custom-domain product pages, > because it would cover the mobile buy bar. Consent is never *asked for* there. A visitor who lands > straight on your sales page from an ad, buys and leaves therefore has no `_ga` and no `_fbp` at any > point — your GA4 and your pixel receive **nothing for that session, including the purchase**. Only > people who accepted the banner earlier, elsewhere on Insy, are measurable. 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`. > **A passing test does not mean your live traffic is measured** > > The test **fabricates** a fresh `_ga` and `_fbp` server-side, so it always clears the cookie > requirement that real visitors routinely fail. It also hardcodes the money as `value: "100"` and > `currency: "USD"`, regardless of your real prices or currency. What the test proves is that the > credentials work and the route is wired — nothing about consent. > **Test events pollute your own stats** > > The test travels through the same queue as real traffic, so it is also written as a genuine > `AnalyticsAction` row and shows up in your Insy stats as a real page view or checkout. Also, the > confirmation only reports that the event was queued — nothing is read back from Google or Meta. ## 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 This is the expected outcome of the cookie rules above. The test invents the cookies; real visitors have to have accepted Insy's banner on some earlier page, and the banner is never shown on community or product pages. Compare Insy's own stats for the same period — if they show traffic and your GA4 does not, this is why. Expected. The GA4 payload carries no `value`, no `currency` and no `items` — only the event name and `community_id`. Revenue cannot be reported in GA4 through this integration. Expected. `value` is sent in minor units without conversion, so 99.00 PLN is reported as 9900. Expected. The digital-product `checkout_initiated` event carries no product ID and is dropped before forwarding. Community checkouts are unaffected. The credentials were rejected by Google or Meta during the save-time check, and nothing was stored — the success toast fires regardless. The provider's message is in the red box that replaced the card; press **Close** on it, then correct the values and connect again. ## Next The payment rails behind the `purchase` events you are measuring. The other cards on the same screen, and what the status badges mean.