Improve Your Ads with Meta Pixel and CAPI

Grupos Inteligentes can help you improve your ad performance on Facebook and Instagram. How? By sending signals that help Meta understand what happens after the click.

With Meta Pixel and the Conversions API (CAPI), you can go beyond visits. With WhatsApp monitoring set up, we also send group join and retention signals. This gives Meta more information to support campaign optimization.

Why look beyond clicks?

A click does not mean someone joined your group. And joining does not mean they will stay.

Tracking these steps separately helps you assess audience quality. An ad with cheap clicks may attract people who leave quickly. Another may bring participants who stay and follow your offer.

Our intelligent signal delivery helps you see that difference, without treating every visit as a group join.

How Pixel and CAPI work together

Meta Pixel: runs in the browser of someone visiting your redirector. The PageView event signals a visit before the handoff to the group.
Conversions API (CAPI): sends events from our servers directly to Meta. With an active subscription and a connected pixel, we send ViewContent for clicks recorded on your redirector.

These are different steps: PageView and ViewContent do not confirm a WhatsApp group join. CAPI complements browser signals, but does not guarantee that every interaction is recorded.

You do not need to write code or create a separate CAPI integration. Finish connecting Meta Pixel in your redirector’s Marketing tab.

What makes signal delivery intelligent?

It is not just about sending more events. Each signal represents a different step. Join and retention events depend on instant WhatsApp monitoring.

The first two events below describe the visit through your redirector. The other six describe group activity, with or without an estimated link to a click.

PageView: visit through the page

PageView is sent by the browser Pixel when the page processes a valid group redirect, outside debug mode.

It indicates a visit through the page, not that WhatsApp opened or someone joined the group. Visits without a valid destination or available slots may follow a different flow and not generate this event.

The timestamp comes from the browser. Blockers, network failures, or leaving the page quickly may prevent Meta from receiving it. A new visit can generate another event: this is not a count of unique people.

ViewContent: click recorded on the redirector

ViewContent is sent through CAPI after our system records the click associated with the destination group. It requires an active subscription and a valid pixel connection.

It indicates that the click reached our system, not that the person accepted the group invitation. Its timestamp is when the system records the click, which may be later than the browser visit.

When available, click, browser, and campaign data help Meta match the activity. ViewContent is not a CAPI copy of PageView: they have different names, timestamps, and identifiers. Do not add them together to count participants.

GroupJoin: join observed in WhatsApp

GroupJoin is sent through CAPI when your connected WhatsApp reports a new join in the monitored group. We need a valid join with a timestamp and an identifiable phone number.

It confirms the observed join, even if the slot count still needs updating. It is not inferred from clicks. Participants already in the group before monitoring do not automatically become new joins.

Confirming a group join does not prove which ad brought that person. The event may include someone who joined through an invitation shared outside your ads. Meta attempts a match using the hashed phone number, without us adding data from a supposedly related click.

The timestamp is the join time reported by WhatsApp. Joins with an unreliable timestamp, an opaque identity, a time before the connection, an age over 24 hours when received, or contradictory information may not generate the event. Leaving and rejoining can generate another GroupJoin; that does not mean another person.

GroupRetained24h: presence confirmed after 24 hours

GroupRetained24h is sent through CAPI when a new check confirms the presence of someone whose join was tracked.

Simply reaching 24 hours is not enough. Confirmation must happen more than 24 hours and up to 48 hours after the join, with tracking still valid. The event timestamp is the check time, not the exact instant the person reached 24 hours.

It indicates observed presence, not message reading, engagement, or a purchase. It uses the hashed phone number without attributing a specific click to the person.

GroupRetained7d: presence confirmed after 7 days

GroupRetained7d follows the same logic, but confirmation must happen more than 7 days and up to 8 days after the join. The clock starts at the tracked join, not at the click or the 24-hour event.

This event also needs a new check and does not prove engagement or a purchase. It does not require Meta to have received the 24-hour event: these are separate milestones.

GroupJoinEstimated: estimated link between click and join

GroupJoinEstimated combines an actually observed join with a click that may be related. It is sent through CAPI with an explicit indication that it is estimated.

The join is real. What is not confirmed is whether the person who joined is the person behind the selected click. Delivery may combine the hashed phone from that join with the available data from the candidate click. This does not make the relationship a verified identity match.

This event is not immediate: the system waits at least 50 minutes after the join before evaluating the relationship. The selection rules are in the next section.

GroupRetained24hEstimated: retention with the original estimated click

GroupRetained24hEstimated uses the same confirmed presence after 24 hours and the same window of up to 48 hours as the confirmed event.

The difference is the browser association: it reuses the candidate click from the original estimated join, without searching for a new click the next day. It can only be prepared if the original estimated join was already queued for delivery and the relationship remains valid. This does not guarantee Meta received the previous event.

GroupRetained7dEstimated: 7-day retention with the original click

GroupRetained7dEstimated uses presence confirmed more than 7 days and up to 8 days after the join, and reuses the same original estimated click.

It does not look for a recent click to explain an old join. Retention was observed, but the link between the participant and browser remains estimated. It does not mean message reading or a purchase either.

How accurate are the estimates?

These selection rules do not establish an accuracy percentage. A close match in time can be useful, but does not prove identity or ad origin.

How the system chooses a candidate click

Before preparing an estimate, the system requires, among other checks:

A join notification for exactly one person, with an identifiable phone and a corresponding retention record. Batch joins are not estimated.
A click in the same group, recorded by our system between 1 and 60 seconds before the join, with valid context for the connected pixel. A click recorded in the same second as the join does not count, because the order cannot be confirmed.
A choice that works both ways: the click is the nearest one before the join, and the join is the nearest one after the click.
A clear margin: if another click or join is less than 5 seconds farther away, the system skips the estimate.
A wait of at least 50 minutes to consider information received later.

Clicks without campaign tags also compete, and so do other people’s joins. The system never falls back to a second choice. If information is missing, the choice is not clear, or analysis exceeds its safety limits, it skips the estimate.

Before sending GroupJoinEstimated, the system checks the choice again with the same rule. If the nearest click changed or a near tie appeared, it cancels that estimate and its future estimated retention events.

Why can an estimate still be wrong?

The click timestamp is when the system records it. The join uses the time reported by WhatsApp. Delivery delays can make these timestamps appear closer together or farther apart.

One person may click while someone else joins through a shared invitation. With missing records, that coincidence can look like a clear match. Competing information can also arrive after the initial wait.

For example, a click recorded at 10:00:00 and a join at 10:00:30 may form a candidate, not proof. If another click happened at 10:00:03, both clicks are almost the same distance from the join. The difference is only 3 seconds, so the system skips the estimate.

The 5-second margin is a safety rule, not a measured accuracy level.

Do not add estimated and confirmed events as separate conversions. They may represent the same activity. Do not add visits, clicks, and retention milestones as new people either.

When are retention events not sent?

The system prefers skipping an event to claiming retention without enough evidence. Confirmed and estimated events can stop when:

The person leaves, disappears from the participant list, or has an identity that cannot be matched to the tracked phone.
There is a gap of more than 2 hours between accepted checks of that participant, or the observation is stale at delivery.
WhatsApp disconnects, reconnects with a new session, or loses access to the group.
You disable monitoring, leave instant mode, change the pixel connection, or lose the required plan access.
Confirmation does not arrive within the 24 to 48 hours or 7 to 8 days windows, always after the first threshold.

Leaving and rejoining starts a new clock. Reconnecting does not prove presence during an unobserved period. So a missing retention event does not prove someone left: there may not have been enough monitoring coverage. Even with regular checks, we do not promise to observe every second between them.

What data helps Meta match the activity?

The data depends on the event source:

ViewContent: may include IP address, browser information, Meta browser and click identifiers, and available location. Country, state, and city are hashed. Available campaign data also accompanies the event.
GroupJoin, GroupRetained24h, and GroupRetained7d: the identifier sent is the observed phone number, transformed into a SHA-256 hash, without adding IP, browser, or identifiers from a candidate click.
Estimated events: may combine the hashed phone from that membership with browser, click, and location data from the original candidate. The relationship is marked as estimated and identity as unverified.

Hashing transforms the phone into a string of characters before delivery. It is not the plain phone number, but it does not make the data anonymous either: Meta can use it for matching. IP addresses and browser or click identifiers are not hashed in this integration.

We do not use the account owner’s name, email, or phone as if they belonged to the person who clicked or joined. These events do not report conversation contents, a sale value, or a confirmed purchase either. Your use of the integration must respect your privacy obligations.

When do events arrive, and why do the numbers differ?

The activity timestamp and the time Meta receives the event can differ:

PageView depends on the browser; ViewContent depends on the click reaching our system and proceeding to delivery.
GroupJoin proceeds to delivery after a valid join. It does not have the mandatory 50-minute wait of estimated joins.
Retention events wait for new checks within the windows explained above.
GroupJoinEstimated can only be evaluated after the minimum wait. The routine that prepares group events runs every 10 minutes; queues and failures can add delays. This is not a promise of delivery in 50 or 60 minutes.

Temporary failures can trigger retries. CAPI retries keep the same event identifier to help Meta avoid counting it twice. This does not merge events with different names or prevent new visits and rejoins from generating new events.

The connection and permissions are checked again before delivery. Events that are too old may be skipped; join and retention delivery discards events older than 7 days from their recorded timestamp. If Meta pixel access is lost, you may need to reconnect in the Marketing tab.

So dashboard clicks, observed joins, and conversions attributed by Meta do not have to match. Filters, date ranges, attribution rules, and monitoring failures can also differ.

How to get started

Open your redirector and go to the Marketing tab.
Click Connect Meta Pixel, authorize your account, and choose the pixel. Finish the connection.
Keep an active subscription for CAPI event delivery. The basic Pixel connection is available on all plans.
To send join and retention events, use the Scale plan with your WhatsApp connected and instant updates enabled. Every 7 days checks do not replace this monitoring.
Use your redirector’s public link as the destination for your ads.
In Meta Events Manager, select the connected pixel and check the events received.

Tip: If you only use the old, manually entered Facebook Pixel ID, connect through your Meta account in the Marketing tab to use CAPI delivery.

How to use these signals in campaigns

After checking that events are arriving, review which conversion options are available for your campaign in Meta Ads Manager. Choose an objective that matches the result you want, not just visits.

Want to attract participants? Analyze confirmed joins without confusing them with clicks.
Want an audience that stays? Also look at retention after 24 hours and 7 days.
Want to compare ads? Use the same period and event type. Always keep estimates separate.

Grupos Inteligentes provides the signals. You remain responsible for your ad settings, audience, and budget in Meta. Sending events does not change your campaign objective on its own.

Next steps

Need help with setup? Email suporte@gruposinteligentes.com.