Since creating EdgeTag, customer feedback has been one of our most important drivers. With our customers, we managed to build a really great product. With feedback, you also get a lot of learning, and we noticed a pattern repeating. When we add a new feature to a specific channel, quite soon, customers would like it on another channel as well. Give it a few weeks; another customer may want to add this new feature to a different channel. We saw that we needed to create a mechanism allowing us to do features and transformations before the event reached the channel processor.
Old flow
This is how the system worked so far. The event would be sent to the Edge. We would first pull the user ID graph and check consent. For consented channels, we will send the event. Each channel would then prepare a payload and send it to a respective endpoint. Let's imagine we have a feature allowing you to rename event names on the fly (you don't need to imagine; we have this feature 🙂). Each channel must add this in the payload preparation step in the current flow. Which would introduce duplication of the code and the headache of maintaining it.
New flow
Let's look at the new flow with Plugins. You can now extract event rename logic in the plugin and do it once. The payload preparation step will use the modified payload and send it to the endpoint. Plugins also allow you to select which channels or event instances they would run on. In the image, you can see that we applied transformation only for Facebook and Klaviyo, leaving Google Ads as is. You can add the same plugin multiple times with different channel configurations.
New events
But we are not stopping there; let's take a new flow image from before and add another possibility. Now, we have a plugin that would like to generate new events on the fly. This is possible as well. Plugins can take an event and create a new one or skip the current one. This gives you complete control of event flow, where you can go wild.
Instead of drawings, let's examine the plugins we build, which use all the above features.
Each plugin can limit its effect to the channel or instance level. This means that you can only restrict the plugin to Meta or limit it to a specific pixel. This would be useful if you run region-specific pixels like the US and EU, where you would like to apply the plugin just to the EU pixel.
HIPAA
HIPAA has strict requirements regarding what data is allowed and what is not to be sent to channels. To ensure that no wrong data goes anywhere, we have a HIPAA plugin that removes all unwanted data for specific channels (even before channel processing) and leaves it for channels users would still like the whole payload, like Google Pub/Sub or their own cloud. Customer can define their own keys that they would like to remove.
Event manipulation
Channels have different requirements, and because we allow customers to use our standard events to simplify onboarding and maintenance and improve performance, this plugin gives you the power to modify event flow. It has two functionalities: Event rename and Keywords.
Event rename
Event rename is meant to manipulate event names. You can decide whether to generate new events out of standard events or replace standard events with your own. You can even decide that the event should not contain product details (except ID and quantity, which is handy for HIPAA).
Keywords
When a Purchase event is triggered, we allow you to create keyword-specific events. Imagine that you would like to optimize your Facebook spend only for two categories. Today, this would be nearly impossible, but with keywords, you can create two custom events and use them for targeting. In the example, we created two events based on the product categories of shoes and hats.
This is just the beginning of our Plugin journey, as we have a lot more plugins in the works and even more ideas about them. If you have ideas or would like to work with us on them, don't wait to join our shared Slack.