Skip to content

Home

Jump to bottom
Vashon Gonzales edited this page Apr 18, 2024 · 2 revisions

Server-to-Server Ad Platform Conversion Optimization Initiative

For further details on Vashon's project, please refer to this link.

  • Project Leader: Vashon Gonzales
  • Support Contact: [redacted]
  • Key Participants: [redacted], Web Engineering, Paid Ads, Data Engineering
  • Slack Channel: #redacted

Background

Paygeon operates within a multifaceted business cycle. We gather user events at the Top of Funnel (TOFU) but achieve business conversion milestones at the Bottom of Funnel (BOFU). Traditionally, we've attributed ads to our TOFU website events. Specifically, when users land on our webpages or navigate to pre-qualification flows (/self-serve, /contact-sales, or /demo-request), we trigger a Segment event and, in some cases, send an event directly to our ad networks to signify conversion. Let's term this as TOFU Ad Conversion 1.0.

We all recognize the potential to optimize our ad expenditures towards what truly matters - our BOFU events. What does this imply? Our revenue is generated not from TOFU events but from actual conversions. The pivotal indicator—the one that truly counts—is when a user becomes a Marketing Qualified Lead (MQL), Sales Qualified Lead (SQL), or becomes a genuine Paygeon user and account holder. These events occur within Hubspot.

The aim of this document and project is to capture TOFU parameters indicating the ad channel and transmit these parameters firstly to our contacts in Hubspot, then to our opportunities, and eventually to our Ad Networks. This is even more critical now, considering the significance of ad optimization in achieving efficient paid spend goals. Let's term this new capability of passing data from SFDC with appropriate upstream parameters as BOFU Conversion 2.0.

Project Scope

This project, being technical and complex, has been ongoing for over 4 months. The complexity lies in transferring parameters from TOFU to BOFU, involving data capture from ad networks and transmission through all our systems, eventually storing and transmitting data in a different object store to Ad Networks.

It cannot be emphasized enough: this endeavor is highly technical and intricate, necessitating careful attention in both development and maintenance.

To specify the scope, our primary focus is to successfully launch the ability to transmit data from TOFU to BOFU for two primary networks initially:

  • Priority #1 Channel 1 (estimated delivery: Feb 1, 2024) DONE ✅
  • Priority #2 Channel 2 (estimated delivery: Feb 1, 2024) DONE ✅

Post-launch, the {redacted} & Ops team will concentrate on launching two new channels in Q3 and supporting updates to existing channels at the request of Paid Ads:

  • Priority #3 & 4: Influencer marketing with {redacted}, shout out from {redacted} & {redacted} (in this order) IN PROGRESS ☐

Future Initiatives: Following the initial launch on August 1, we will continuously enhance this system by:

  • Validating successful data transmission and reconciliation between our opportunity table and ad network conversion tables (expected delivery by XYZ ~8/15/2024)
  • Reviewing and enhancing the DBT export tables to manage errors observed in these HT syncs. Refer to the section below for DBT improvements starting 8/8/2024.

Architecture Overview by Channel

image

Due to the technical nature of this task, each channel will operate with slight variations. Let's first discuss the high-level workflow, then delve into specific technical architectures on a per-channel basis.

High-Level Workflow

  1. Ad is displayed to user. Depending on the channel, there will be a clickable link embedded with parameters in the URL (e.g., gclid=XXXXX or fb_id=ZZZZZZ).
  2. User clicks the ad, redirected to https://Paygeon.com.
  3. We trigger Segment events to capture the page view and tracking attributes.
    • These elements are incorporated into TOFU Ad Conversion 1.0.
    • Data capture and processing occur within our codebase [here](link to GitHub).
  4. User proceeds to pre-qualification flow.
    • We trigger events via Segment and Google Tag Manager to our networks, including parameters about the Ad Network and specific ad that directed the user.
    • This remains part of TOFU Ad Conversion 1.0.
  5. A contact is created in Hubspot with referral parameter information for the ad network and ad unit.
  6. The contact is synchronized to Hubspot with associated TOFU referral parameter information for the ad network and ad unit.
  7. User completes the Paygeon application.
    • The user is now in Hubspot.
    • An opportunity is created [assuming sales success].
    • When the opportunity is created, we retrieve the contact and append the opportunity with TOFU parameters.
  8. At this stage, various actions may occur. BOFU Ad Conversion 2.0 assumes that as the prospect progresses from a lead to an opportunity, MQL, SQL, and eventually closed opportunity, we "listen" to these stage changes and record/issue events back to the Ad Network via Hightouch. Implementation specifics vary by network.

Conversion Events, Fields & Data Locations

We aim to send 6 "conversion events" from BOFU to our Ad Networks, each representing a stage change in Hubspot. The concept is that when a stage changes, the associated opportunity and records (e.g., gclid, or contacts with fb_id) will be stored and relayed back to our Ad Networks via Hightouch.

Channel Implementations

  • Google Ads

    • Enabled via Google Ad Conversions in Hightouch, utilizing "store" conversions as the closest offline event analog, which aligns with BOFU Conversion 2.0 models.
    • Reference: [redacted]
    • Required fields:
      • gclid
      • gclid_ts

  • Facebook Ads

    • This integration is distinct and more intricate than Google due to not accepting the fbp parameter from TOFU. Instead, Facebook requires an event with email, IP, and user agent string to match the user to an executed event.
    • Known Limitations:
      • Facebook operates as a black box, potentially crediting itself generously upon matching impressions or clicks, leading to potentially inflated conversion counts.
      • Due to Facebook's audience predominantly comprising non-business users, our approach involves enriching SFDC contacts with personal email, relying heavily on IP and user-agent string for conversion tracking—rendering mobile view conversions somewhat inconclusive.
    • Reference Documentation: [redacted]
    • Required fields:
      • fb_p
      • fb_c
      • fb_ts

  • Bing Ads

    • [2 docs redacted]
    • Required fields:
      • Conversion Name
      • Conversion Time (msclickid)
      • MSCLKID (msclickid_ts)
    • Microsoft Click Id Tracking in Amplitude: [redacted]
    • Scoped work: [Related ticket]

  • TikTok Ads

    • A straightforward integration akin to Google, capturing ttclid (TikTok Click

Id) and mapping it to opportunities within SFDC.

  • Required fields:

    • TikTok Click Id - ttclid
    • tt_ts (timestamp of click)

  • Impact Radius - Affiliate Platform

    • Our current integration with Impact via Hubspot targets "Application Completed" and "Closed Won" conversions.
    • To accomplish this, we require both an ID and Timestamp passed from the Web —> SFDC Opportunity:
      1. Pass the Timestamp value to Hubspot (impact_xxx_clickid_ts)
      2. Pass impact_xxx_clickid_ts to SFDC on the Contact and convert it to Date/Time format
      3. Pass both impact_xxx_clickid and impact_xxx_clickid_ts to the SFDC Opportunity, ensuring no overwrites by subsequent updates to the field on the Contact
    • Tracking: [Related ticket]
Clone this wiki locally