This project was to implement an advanced technical capability that would improve the efficiency of our paid ad program. It had stalled for 4 or 5 months before I joined Ramp, and so it was one of the first things I jumped in to accomplish. It is highly complex from both a tech and collaboration perspective (requires many tools, people all working together).

Ad platform conversion optimization is a crucial step in running a successful MarTech operation. We discuss how and why to do a project like this in-depth in the 

MarTech course I'm launching with Reforge in the Fall of 2023.

At the time, we were focused on reducing CAC (customer acquisition cost), and this project allowed us to focus our paid ads program to the bottom of the funnel making it more efficient.

The main reasons for it stalling were because there wasn't clear ownership or the technical acumen to drive it to completion. This project was complicated technically and the leadership team hadn't understood how long it would actually take to accomplish (multi-sprint) and maintain (resources). It can be easy for leadership teams to trivialize projects like this, making it seem easy when it's the opposite.

We prioritized by listening to our customer: Paid Growth.

This project was designed to help them reduce the CAC of paid ads spend, so naturally we asked them – what channel is most important to start with? Which one is going to have the most bang for our buck?

Martech is all about talking to and listening from your partners and the stakeholders you serve with technology.

This initiative was completed and has been live since August. In terms of results, we hit our CAC targets in 2022, and this has provided the foundational ability for us to do more advanced paid ad measurement like incrementality.

Looking back on this project, I think it was actually fairly successful. One of the key learnings is that a project of this level of nuance requires some strong project management orientation. There's a very high likelihood of bystander syndrome, where people don't know who's in charge because it involves so many different pieces. And so, electing a person to drive each element of the project forward is really important.

Ticketing was very important. For every single one of these channels, we had six or seven sub-tickets. For instance, it was the web engineer's job to add the thing, then it was the MarOps person's job to add it to HubSpot, then it was another person's job to add it to Salesforce, and then it was another person's job to pull it into the warehouse, and then it was my job to get it back up.

Because of that, there was a lot of potential for things not to go well because things had to be done in a particular order and couldn't be parallel pathed. It also meant that there was high potential for things to slow down if one person missed. That's again where project management and organization really matter. You have to have the person do it in a day so the next person can do theirs in a day and so on. If anybody in that cycle misses their work, then the whole project is stalled by that single individual. You have to be upfront about the cadence of work so people know how to prioritize effectively.

Austin Hay

See how I planned and implemented a complex technical project to improve Ramp's paid ad efficiency.

Server-to-Server Ad Platform Conversion Optimization Project

Key Stakeholders: Martech, Web Engineering, Paid Ads, Data Engineering

Ramp runs a complex business cycle. We collect user events at the Top of Funnel (TOFU), but convert business opportunities at the Bottom of Funnel (BOFU). Historically, we have run ad attribution against our TOFU website events.

Specifically, when a user landed on our web pages, or navigated to the pre-qualification flow (/self-serve, /contact-sales, or /demo-request) we would issue a Segment event and [in some cases] issue an event directly to our ad networks with an event to represent the conversion.

We all see and agree that there is an opportunity to optimize our ad spend against the juice that really matters - our BOFU events. What does this mean?

Our business makes money not when people perform these TOFU events. These are just leading indicators of the conversion. The lagging indicator– the indicator that actually matters– is when a user becomes an MQL, SQL or closes and becomes a real Ramp user and account. These events happen in Salesforce.

The goal of this document and the purpose of this project is to capture TOFU parameters that indicate the channel of the ad, and successfully pass these parameters first to our contacts in Salesforce, then our opportunities and eventually our Ad Networks.

This is even more important today in a world where we consider the importance of ad optimization towards achieving efficient paid spend goals. Let's call this new ability to pass data from SFDC with appropriate upstream parameters BOFU Conversion 2.0.

This is a technical and challenging project to bring to success. 

As of the updating of this document, the project has gone on for over 4 months.

 This is because passing parameters from TOFU to BOFU is not a trivial task. It involves capturing data from ad networks and passing data through all of our systems. It then involves passing data in a different object store to Ad Networks.

It cannot be stated strongly enough: this is a highly technical and complicated feat that will require attention to build and maintain.

For the purposes of clarifying scope, the focus of this project is to successfully launch the ability to pass back data from TOFU to BOFU for two key networks to start:

Priority #1 Channel 1 (est. delivery Aug 1, 2022) DONE ✅

Priority #2 Channel 2 (est. delivery Aug 1, 2022) DONE ✅

Once these channels have been launched, the Martech & Ops team will focus attention on launching 2 new channels in Q3 as well as supporting updates to existing channels at Paid Ads request:

Priority #3 & 4: Channel 3 (in this order) DONE ✅

Future Work: After the initial launch on August 1, we will continually improve this system through:

Validating the data is successfully being transmitted and matches between our opportunity table and ad network conversion tables (expected delivery by XYZ ~8/15/2022)

Reviewing and updating the DBT export tables to handle errors seen in these HT syncs. See section below for DBT improvements starting 8/8/2022.

Due to the technical nature of this task, each channel will operate slightly differently. First, let's talk about the high level way that things will happen, then refer to the specific technical architecture on a per channel basis:

Ad is shown to user. Depending on channel there will be a link that the user clicks. This link will have parameters that get embedded into the URL (ex: gclid=XXXXX orfb_id=ZZZZZZ)

User clicks ad, redirects to https://ramp.com

We fire Segment events capturing the page view and attributes for tracking.

We pass back these elements as part of TOFU Ad Conversion 1.0

We capture this data in our codebase here: [link to Github]

We fire events via Segment and Google Tag Manager to our networks with the parameters about the Ad Network and specific ad that drove the user.

Contact is created in Hubspot with referring parameter information for the ad network and ad unit.

Contact is synced to Salesforce with associated TOFU referring parameter information for the ad network and ad unit.

Opportunity is created [assume sales success]

When the opportunity is created, we grab the contact and stamp the opportunity with the TOFU parameter.

At this moment in time, many things can happen. BOFU Ad Conversion 2.0 assumes that as the prospect converts first to an opportunity, MQL, SQL, Opportunity Closed we "listen" to these stage changes and record/issue events back to the Ad Network via Hightouch. In practice this engineering is different depending on the network.

Conversion Points, Fields & Location of Data

There are 6 "conversion events" that we want to send from BOFU to our Ad Networks. Each of these represent a stage change in Salesforce.

The generalized idea is that when a stage change occurs, the opportunity and its associated records (gclid, or contacts with fb_id) will be stored and passed back to our Ad Networks via Hightouch. See the above architecture diagrams for specifics about how this will work.

Google Ads is enabled via Google Ad Conversions in Hightouch. We use "store" conversions because this is the closest analog to an offline event, which is the representative models for BOFU Conversion 2.0.

https://hightouch.com/docs/destinations/google/#store-conversions-options-store-conversions-only

This ad integration is different and more challenging than Google because it does not accept the fbp parameter that comes from TOFU. Instead, Facebook expects an event with email, IP, and user agent string in order to match the user to a performed event. We have no visibility into how this matching occurs.

Facebook is a black box and therefore may generously credit themselves whenever they match an impression or click. Since they are matching by email or IP, this could result in conversion that isn't actually real.

Facebook isn't a network of business users. We will design our approach to enrich SFDC contacts with personal email, but this means that most conversion mapping will be done on IP and user-agent string. For mobile views and conversion this will mean that our conversion through this will effectively be meaningless.

https://hightouch.com/docs/destinations/facebook-conversions/

Facebook Reference Documentation: [Internal document]

https://developers.facebook.com/docs/meta-pixel/reference#standard-events 

Above are set on the opportunity. Then we reverse lookup the associated contact and use the following:

first_name, last_name, email, IP, user-agent string

https://hightouch.io/docs/destinations/bingads/

https://docs.microsoft.com/en-us/advertising/campaign-management-service/offlineconversion? view=bingads-13#elements

Microsoft Click Id Tracking in Amplitude: [Amplitude link]

This is a simple integration that will work much like Google. We will capture ttclid (The TikTok Click Id) and pass it to SFDC so it is mapped to opportunities.

Affiliate Partnership Management Platform. Currently we have an integration with Impact via Hubspot and our conversion definitions are "Application Completed" and "Closed Won".

Plan is to scrap our integration with Hubspot and move to an integration with Segment for Web related events and over the next few weeks send the same BOFU Conversion Events (see above) as we do with the other platforms to Impact via Hightouch syncs.

To do this we need both an ID and a Timestamp passed from the Web —> SFDC Opportunity:

We currently capture the Impact Click Id in Hubspot (impact_xxx_clickid). The equivalent field is on the SFDC Contact. We need to:

Pass the Timestamp value to Hubspot(impact_xxx_clickid_ts)

Pass impact_xxx_clickid_ts to SFDC on the Contact and get it into a Date/Time format

Pass both impact_xxx_clickid and impact_xxx_clickid_ts to the SFDC Opportunity and ensure that it is NOT Overwritten by any updates to the field on the Contact

Because there is no integration between HT and Impact Radius, we are instead sending conversion data directly to the IR conversion API.

We will use the IR conversions API to do so

: https://integrations.impact.com/impact-brand/reference/submit-a conversion

This API requires the following fields…

Ad Platform Conversion Optimization Project at Ramp

Server-to-Server Ad Platform Conversion Optimization Project

Context

Sign up to see more