Overview | Analytics
What capabilities can be unlocked with FlyCode Analytics?
Today, data-oriented team members who define events for the developers, go about doing so in a few ways. Good case, they might create tables in Jira, Confluence or Notion. Bad case, however, they might create an Excel table or, worst case, a Slack message.
At FlyCode, we want to help them do it better. By defining new events and editing existing ones in a structured system, data team members will be able to manage events without fault and monitor their implementation status live. This will terminate back and forth around the most pressing question they have for other teammates: “is it ready yet?”.
Data team members would usually monitor their event in Dev and Production with live events lexicons (such as the one in Mixpanel) or, if they’re comfortable with code, they might take a look in the code for themselves. If not, some might ask a developer about the events and some might just hope that the developer updates their events tracking plan and continuously do so as they make changes to events - which, unfortunately, doesn’t happen most of the time.
What does happen commonly, though, is that events, requested by the data person or not, get implemented to Dev - - or even Production(!) all the while the data person isn’t aware about those changes and is only informed after the fact, if at all.
With FlyCode, however, not data team members nor developers would need to worry themselves with status updates, visibility or even organisation - we do it all for you, automatically. FlyCode will update your monitoring plan in real-time according to live changes to the code so it would be continuously maintained automatically and will notify all data team members to whom these changes are relevant, while continuously making sure everything is up-to-date. Furthermore, FlyCode will provide insights and crucial information such as an event’s context - in which component and page the tracking occurs and where it is in the user’s journey. Additionally, FlyCode will make sure to notify the data team member whenever a pull request includes changes to anything that’s analytics related, enabling them to always be a few steps ahead in the process, be included in the review process and by so eliminating unwanted changes and nipping potential problems in the bud. Being closer to the engineering team and gain full visibility has never been easier.
FlyCode also shows you important insights such as which events and properties are no longer in the flow or are no longer used in the code, which will help keep your plan clean and tidy, and also save money for your organisation on monitoring unused events.
With Analytics automation, making analytics changes to analytics is easy. It not only saves the developer time, but makes sure to leave as little room for mistakes as possible, while also automating communication between the data team member and the developer and keeping everyone in the loop and up-to-date. You can use FlyCode automation to automatically translate the data requirements set by the data team member to the schema in the code - FlyCode will automatically generate the code!
All that’s left for the developer to do, is to call the relevant event function in the code.
FlyCode Analytics was made for data team members with developer friendliness in mind. Here at FlyCode we aim to make everyone’s tasks easier, without adding to anyone’s workload nor requiring people to familiarise themselves with additional confusing tools.
Our goal is to seamlessly integrate with the current workflow of data team members and developers, while providing a substantial amount aid and improvement. We do this in a few ways, the first of which is that for developers, FlyCode operates directly in GitHub just like another team member. It does not require any integration done by them and the developer doesn’t need to use FlyCode at all - all the while the data team member will still benefit from it. What more, is that FlyCode will provide the developer with solid and detailed definitions of the data requirements set by the data team members right in the same ticket and/or even as a PR with the required event schema.
By having solid task and data definitions in the communication between data and engineering, we can spare the teams exhaustive exchanges such as “which events are in the code?”, “where is this event tracked” or “when will this event be implemented/was it already?”.
Last modified 1mo ago