WIWOTW: Facebook CAPI Migration from Segment to GTM

Adam King
5 min readSep 16, 2022
Photo by Carlos Muza on Unsplash

TL;DR My process for working through a complex project at work, Migrating a Facebook Conversions API set up in Segment to GTM across multiple workspaces.

Introduction

Hey Everyone! I haven’t posted in a while, but I recently had an idea to start talking about all the cool things I get to work on at my job. I am a junior analytics engineer at a digital marketing agency, which means I work on a lot of different clients. My specialty is pixel implementation and I do most of my work in Google Tag Manager (GTM). A project I worked on gave me the idea to start a “What I worked on this week” (WIWOTW) series.

What I worked on This Week

This week I was given a doozy of a task that definitely left my brain feeling like mush when it was all done. It was initially coined as segment migration for one of our client’s sites. The client currently had some pixel tracking setup in their Segment account, and my role in this task was to move the tracking out of Segment and into GTM.

Sounds easy enough right? I just needed to move the pixels out of one platform and into another. However, the thing that made this task so interesting was the way the client’s website/platforms were set up.

If you’re not familiar with Segment it’s considered a customer data platform that provides you a unified hub for pixel tracking/customer segmentation. You can plug multiple “sources” into the platform that will send data in. Then you can set up “destinations” and map the data coming into Segment to the correct parameters of the destination you're trying to send to i.e. Facebook, Google Ads, etc.

So if the client already had tracking setup, then why did you need to move it to GTM?

Great question you astute reader! Segment is great in that it provides a single platform to manage data going to multiple ad platforms, but it’s not a tag management system (TMS) like GTM. That means to troubleshoot any tracking issues you need access to the source code of a client’s site. GTM, however, you customizate/troubleshoot all you want, and the only thing you need access to is the client’s GTM container.

Therefore, I was tasked with moving some of the tracking out of Segment and into GTM so that we could have greater control over implementations and tracking issues that pop up down the line. But what made this task so mind splitting?

Container Mania

The first roadblock was the client had three separate GTM containers for specific URL’s of their site. This meant that they had a container dedicated to one page, and if you clicked on a certain link you would be taken to another page where the tracking was coming from a different container.

This client’s website was also set up for different countries, which meant the tracking I needed to implement needed to only fire on specific country URL’s.

The separate GTM containers weren’t too big of a deal, but they did add a layer of complexity to a task that was slowly starting to grow in scale. It wasn’t until I checked the Segment side of things that I really knew how much time I was going to need.

Segment Considerations

Upon initial glance, their Segment was pretty understandable. It looked like I would really only need to focus on two sources, and after some further investigation, I would only need to migrate Facebook Pixels out. Usually, that’s not so bad, but I saw that both sources had Browser Pixels and Conversion API setups.

The reason this added more complexity is the server side of things. Setting up Browser pixels is super straightforward and is something I do almost every day. But server tags are different. It’s not a matter of just adding a little code snippet into the GTM container. Luckily my company has a current solution we utilize for CAPI, but even with that, it meant a more thorough QA process and way more stuff to look over when it was done.

The next shock came when I saw that one of the sources had 6 events currently set up and the other source had 7. That meant that I now had 13 events to implement, across 3 GTM containers, and if you hadn’t already pieced it together there were only 2 segment sources.

After realizing that what I thought would be a pretty straightforward task just catapulted into something that would take a lot of time and energy, I immediately jumped into planning how to go about tackling this task.

Plan of Attack

The first thing I needed to do was figure out where these events were firing. That meant I had to put on my detective hat and dive into the client’s websites to see what I could use as my triggers / where the heck these events were coming from.

Next, I had to map out which containers in GTM would house the events set up in Segment. After watching the live view of the debugger in one of the Segment sources, I was able to find a Page call that revealed the source encompassed two of the GTM containers. Now that I knew where everything needed to go, I was in a much better position to start the implementation.

Previous Work

The next roadblock I hit came from theGTM containers themselves. Every single one had a previous FB setup with multiple pixels contained in them. That meant that I now had to compare what I was planning to set up to what was currently in the container. After parsing through the existing tags I saw a couple of issues that I would need to address before the implementation.

Now that I had the containers in a good spot to start I went about implementing the FB CAPI events. The final result ended up being a 1–6–6 split of events across the GTM containers. Once I had the events implemented I was able to start the QA process.

This was where I hit another roadblock. During the QA process, I couldn’t turn the Segment destinations off, because that would kill the client’s current tracking. That meant that as I was trying to QA the GTM events, I had to parse out which one’s were coming from Segment and which were coming from GTM.

Luckily the event ID’s made this task much more manageable, but by this time it felt like I was never going to get this task done. After what felt like forever, I was able to make sure everything was firing appropriately and the implementation ended up looking good.

Conclusion

As I stated in the beginning this task really gave me a run for my money. As tired as I was after working on it, I felt comfortable knowing that even though I kept hitting roadblocks, I was able to work through them to accomplish the task. It was for sure the most complex Facebook CAPI setup I have done so far, and I’d be lying if I said I wanted to do another one anytime soon.

If you have any questions about the technologies or literally anything about what I just talked about feel free to reach out to me! You can find me on LinkedIn and I’m happy to answer any questions about my position or what I do. I also love feedback so if you’re in the analytics world and have any tips or better ways to do things, I would love to hear them.

--

--

Adam King

Software engineer sharing stories of my experiences in a coding bootcamp and beyond.