Attributing broker deposits to Meta ads via RudderStack through a WhatsApp funnel

Other
, , , , , ,
1

The client's problem

We need an experienced Meta Ads tracking/CAPI specialist to implement accurate end-to-end conversion tracking for this funnel:
Meta Ad → Landing Page → WhatsApp → Landing Page 2 → Broker Registration → Confirmed Deposit
Our goal is to feed Meta the strongest possible downstream conversion data so campaigns can optimise towards real registrations and funded clients, rather than just clicks.

Our broker platform provider has already confirmed:

  • UTM parameters and Meta click ID are captured and stored against registered clients.
  • A confirmed deposit event can be passed through RudderStack to Meta, including the deposit amount.
  • Integrations can be built using the available APIs/webhooks and RudderStack.

We need help implementing and validating tracking for:

  • WhatsApp CTA clicks
  • Actual WhatsApp conversations/messages initiated, if technically possible
  • Successful broker registrations
  • Successfully confirmed/credited deposits
  • Deposit amount + currency
  • Repeat deposits where appropriate
  • Attribution of these events back to the original Meta campaign/ad

WhatsApp attribution is particularly important.
Our ads do NOT go directly to WhatsApp: Meta → our landing page → WhatsApp
We can already track someone clicking the WhatsApp button.
We want to know whether we can detect when that person actually sends us a message and preserve their attribution when they later register and deposit.
This may involve WhatsApp Business API/webhooks, Meta CAPI, RudderStack, _fbc/_fbp, click IDs, UTMs, first-party IDs and/or server-side tracking.
We want someone who can recommend the best architecture, implement it and test the complete journey in Meta Events Manager.

Please answer these questions:

  1. A broker stores the original visitor’s Meta click ID + UTMs and can provide a server-side confirmed deposit event + amount. How would you send and attribute this conversion back to Meta?
  2. How would you detect an actual WhatsApp message/conversation after someone clicks WhatsApp from our website, rather than merely tracking the button click?
  3. Someone clicks our Meta ad Monday → messages us on WhatsApp → registers Tuesday → deposits Wednesday. How would you preserve attribution across that journey?
  4. How would you handle first deposits vs repeat deposits when sending conversion data to Meta?
2

My solution

1. «A broker stores the original visitor’s Meta click ID + UTMs and can provide a server-side confirmed deposit event + amount. How would you send and attribute this conversion back to Meta?»

1.1

RudderStack has no native «Event Stream Source» integration with any broker platform: rudderstack.com/docs/sources/event-streams/cloud-apps

1.2

Therefore, to receive data from a broker platform to RudderStack, it is necessary to create and configure an «Event Stream Source» of the «Webhook» type in RudderStack.

1.3

The URL of this webhook must be specified on the broker platform.

1.4

When a deposit is credited to a client's account, the broker platform will send an event payload to this webhook URL.

1.5

This webhook will be the source of an «Event Stream» pipeline in RudderStack.

1.6

To send the event payload to Meta, connect this source to a «Facebook Conversions» destination.

1.7.

Connect a «Transformation» to this destination:

This «Transformation» must convert the event payload (§1.4) from the broker platform format to the format required by the «Facebook Conversions» destination (§1.6): rudderstack.com/docs/destinations/streaming-destinations/fb-conversions/cloud-mode

2. «How would you detect an actual WhatsApp message/conversation after someone clicks WhatsApp from our website, rather than merely tracking the button click?»

Configure a webhook in the WhatsApp Business Platform to subscribe to the messages field:

3. «Someone clicks our Meta ad Monday → messages us on WhatsApp → registers Tuesday → deposits Wednesday. How would you preserve attribution across that journey?»

3.1

When a client messages on WhatsApp, assign them an identifier («Client ID») and save it together with the client's phone number in the database.

3.2

The «Landing Page 2» URL sent to the client must contain the «Client ID».

3.3

When the client registers with the broker on «Landing Page 2», the «Client ID» (passed via a UTM parameter) is stored in the broker's database.

3.4

When the client makes a deposit, the «Client ID» is sent to RudderStack (§1.4).

3.5

At the §1.7 stage, the «Transformation» will fetch the client's phone number from the database (§3.1) via an API using the «Client ID» and add its normalized hash to the event payload for Meta (§1.6).

3.6

Meta itself will match the event to the client's «Meta Ad → Landing Page 1» click using the client's WhatsApp number.

3.7

It can additionally help Meta if both landing pages are hosted on the same root domain.

3.7.1

After the «Meta Ad → Landing Page 1» transition, save the _fbc cookie to the client's browser.

3.7.2

At stage §3.3, «Landing Page 2» will extract the _fbc cookie and save its value in the database, and then this value will be fetched by RudderStack and passed to Meta according to §§3.4-3.5.

4. «How would you handle first deposits vs repeat deposits when sending conversion data to Meta?»

It is best to use the customer_segmentation parameter:

This field accepts one of the following predefined enum values:

  • new_customer_to_business: The user is a new customer to the business
  • existing_customer_to_business: The user is an existing customer to the business