Avo Codegen overview
Codegen produces type safe code for implementing analytics.
- The "data designer" specifies the event structure in the Avo Tracking Plan, and which platforms should send the event
- then the developer who implements analytics can use Codegen to implement the analytics calls per each analytics event
Codegen simplifies implementation and makes sure it is correct and consistent across all platforms.
For example, instead of Android calling
analytics.track("game started") and iOS calling
analytics.track("gameStarted") , they both call
Avo.gameStarted(), and the Avo function takes care of the spelling of the event and property names as they get passed into the analytics SDK.
In other words, event and property naming is abstracted entirely away from the event implementation layer, ensuring that events and properties are named the same across all platforms, teams and code bases.
Codegen is our way of increasing the robustness of the analytics implementation and simplifying the implementation process.
Adopting Codegen is not required to get value from Avo - many companies have their own ways to achieve robust analytics implementation and prefer to stick to them rather than adopting a new approach.
Avo is designed to be efficient and powerful without the Codegen, providing advanced tracking plan management and observability with Inspector. The decision to use Codegen is usually in the hands of the engineering team on each platform. If you prefer to use a different approach for implementing your tracking code Avo can still help you by providing a platform to collaborate and align on the tracking specs, and by providing clear specs for the suggested tracking changes.
Learn more in the Codegen setup docs.
Codegen works with any analytics tool, whether it's any of the common event logging SDKs (e.g. Google Analytics 4, Segment, RudderStack, mParticle, Snowplow, Amplitude, Mixpanel, PostHog, FreshPaint, Pendo, etc) or an homemade API or SDK.
When designing the tracking plan you configure the list of data destinations for each source. In the generated code each destination is represented as its own Destination Interface in the initAvo method. This is how Codegen routes data, locally in your client (without the data ever going through Avo's servers), to the correct destination based on the source/destination connections you've defined in the Avo dashboard.
In the Avo Tracking Plan you can configure which analytics actions should be included in Codegen (for example you might want to update user properties or log revenue along with logging an event), and Codegen will handle calling all the relevant Destination Interface methods. All you have to do is call the generated function in your code base and pass in type safe key-value pairs, and the Codegen will take care of the rest.
Learn more in the Codegen tech deep dive docs.
No. None of your events ever go through Avo servers. They go directly from your devices (whether that's a front-end client or a server) to the data destination.
This sometimes called device mode. With CDPs, you can choose between Cloud-mode or Device-mode (opens in a new tab):
- In Cloud-mode, your events go through the CDP servers. Your devices send the events to the CDP cloud (aka the CDP Servers) and the CDP cloud sends them to the analytics destinations.
- In Device-mode the events go directly from your devices (whether it's a front end client or a server) to the analytics destination.
In this regard, Avo works like Device-mode.