Segment as a TMS vs Google Tag Manager

This post is dedicated to all the great marketers, product teams, and analytics people out there looking to improve the user experience on their website by having purchased Segment. When it comes to deploying Segment on the web, Segment vs Google Tag Manager is a topic I’ve come across a number of times with clients.

I want you to know that comparison is not a valid one, because Segment is so much more than a TMS, and GTM (or any other tag manager) is so much better at capturing web click stream data than Segment-as-a-TMS is.

The questions that always come up are:

• Do I need GTM (or any other TMS) if I have a Segment?
• Should I integrate GTM within Segment?
• Should I implement Segment through GTM?

I’m going to convince you why the answers to those questions are: Yes, No, Yes… and by the way, I’m going to let you in a secret, this applies to every CDP. There is a reason why Tealium’s AudienceStream is a great CDP, and it grew out of TealiumIQ – the tag manager. Adobe recommends streaming data to its own CDP using the Web SDK extension available through Adobe Tags.

Segment is not a replacement for a tag manager, no matter how many times Segment throws shade at a TMS throughout its documentation. Nor how many times it promotes itself as a tag manager replacement.

Segment.is.a.Customer.Data.Platform.

A really good one at that too, but this post will not explore the CDP part of Segment. Instead, we will focus on the use case of Segment-as-a-TMS. When you purchase Segment you can also purchase (or it may be included) a professional service package that will onboard you through the implementation. I think it’s a good process, but they will do everything possible for you to install their SDK natively in your web application and forget about data layers and tag managers. How come?

I see one simple truth: it’s strategically better for Segment to be embedded on your site because it will be harder for you to take it out. As a tech-agnostic data consultant, I have to ask myself, what is strategically better for you? Probably implementing a generic data layer that you can leverage for any tool.

But putting that aside, would implementing Segment-as-a-TMS within your web application be objectively better than implementing it in GTM? I don’t think so, and below I compare what I see are the Pros and Cons of considering either approach.

Segment Approach:

Pros:

• Centrally managed in Segment.
• Leverages existing turnkey Segment-to-vendor integrations where possible.
• Many one-stop-shop vendors have integration with Segment, like Shopify or Vimeo.
• Able to implement new vendors and load historical data captured up to that point.
• A standardized data model normalizes data to vendors.

Cons:

• Requires development resources familiar with Segment to implement.
• More effort is to hire resources with Segment-specific knowledge as they are not as common.
• Requires development support to implement and maintain Segment specific JavaScript tags.
• Segment integrations are rigid-box and any customization requires dev support to deploy in-line JS track calls.
• Migrating off of Segment will be a large effort.
• Not as robust as event listener and trigger detection as GTM (or any other TMS).
• Overlapping confusion between Segment as a TMS and GTM, for ex:
  • Must remember that you are not able to scrape triggers in Segment, but yes in GTM.
  • Who implements a marketing pixel request, Segment, or GTM?
• Segment is a paid solution, and GTM is free.

Level of effort:

Website developers have to know when to use each of the following Segment-specific calls.

    analytics.identify()
    analytics.track()
    analytics.page()
    analytics.group()
    analytics.alias()

For ex:

    analytics.track("User Registered", {
        plan: "Pro Annual",
        accountType: "Facebook"
    });

The biggest question organizations should think about is who will maintain the implementation of Segment on your web app? Does your development team have the bandwidth, and prioritization, to maintain Segment? Are you OK maintaining Segment on retainer for ongoing support? How big is the skill talent pool for Segment if the resource that implemented Segment along with onboarding services leaves the organization?

Softcrylic Approach:

Pros:

• Centrally managed through a data layer.
• No threat of contract renewals to be able to access your tags. GTM is free.
• Still able to send web event data to Segment regardless and use Segment as a CDP
• Tag Management agnostic: use GTM / Adobe Tags / Tealium / etc, migrating from GTM to another a lesser effort.
• Leverage robust event listener and trigger detection from GTM.
• Less effort to hire new resources to implement or maintain as data layers are industry standard.
• Developers do not need any tool-specific knowledge to implement.
• Marketing data is organized in a user-friendly data layer.
• Data collection customization without dev team support is possible to the extent website allows for DOM scraping.

Cons:

• Development support does not go away, but is limited to updating data layer pushes – a low-effort task.
• Easy to stray from best practices as there is no defined set of rules to design and implement a data layer.
• Limited out-of-box vendor templates availability, but growing through a community of developers, and still able to leverage all Segment integrations.

Level of effort:

Data layer development requires a similar level of effort a developer would have to do to implement in-line JS calls for segment, but without having to know the corresponding Segment-specific syntax. Every type of call follows a standard syntax.

For ex:

    dataLayer.push({
        event: "User Registered",
        plan: "Pro Annual",
        accountType: "Facebook"
    });

The first thing I’ll ask you. Did you find it weird the analytics.track() call example looks a lot like the dataLayer.push() example? It’s because ultimately, it’s the same thing. The analytics.track() code pairs an event “User Registered” with a payload, “Plan” and “Account Type”… while the dataLayer.push() code does exactly the same. You would be asking your developers to implement the example for Segment the same way you would be asking them to implement a generic data layer on your website. Only this time you are tying yourself to Segment-specific knowledge, and your developer will have to know when to use identify(), track(), page(), group(), or alias()… vs. only using dataLayer.push() for any situation.

The second thing I’ll point out is when you implement Segment via a tag manager, you still get all the amazing benefits of Segment. Segment will still standardize your data. It will still allow you to send your data to any of its destinations. You will still be able to backfill historical data to any destination. You get all the benefits of Segment while retaining control of your app, and breaking yourself apart from development cycles when you need simple tagging updates.

Third, I purposefully left out an important consideration from the comparison, because it could be interpreted as either a Pro or a Con depending on your situation. When you implement through a data layer you are effectively adding a step in your data collection process. Segment’s approach can be interpreted as 3 steps: “JavaScript > Segment > Destination”, vs Softcrylic’s approach as 4 steps: “data layer > GTM > Segment > Destination”. However, you take this step so you can free yourself from Segment contracts, and remain flexible. This is a small investment that will pay dividends for you down the road. Your engineering team will be happier, your marketing team more nimble, AND you still retain all of Segment’s benefits.

In summary, let your developers develop your application, and let your analytics team tag your analytics. Whether it’s GTM or any other tag manager. If your organization is large enough, chances are you have better-skilled people to manage implementing Segment within a tag manager, and a development team who can prioritize web development, data layer included. If your organization is lean and you don’t have the resources to implement a data layer, as I have seen many times with Google-stack-oriented teams, integrating Segment through GTM is even more important for you. You can rely on all the GTM built-in triggers and variables and rarely have to negotiate with a developer.

Don’t hardcode Segment with in-line JavaScript in your web app, use a data layer and tag manager instead.