Background/Goal
Upon completion of T343311, the next steps are to update the Metrics Platform APIs in order to submit core interaction events.
KR/Hypothesis(Initiative)
If we develop a centralized experimentation platform that can define, deploy, and get feedback on experiments, Product teams will develop and instrument their features for experimentation.
As part of SDS 2.5.1, if we update the Metrics Platform APIs, feature teams will be able to submit events using core interaction schemas, thereby fulfilling a dependency for the centralized experimentation platform.
Notes
Extending the current API starts with a submit method to which we can add basic metadata (dt, etc).
With the new core interaction fragments and schemas, we can also submit clicks i.e.:
- submitClick()
- submitPageView()
- submitInit()
- submitFunnelEnter()
- etc.
Though we cannot model all the possible use cases in client code, we can provide the base interaction schemas to capture standard data with every event and provide methods for submitting additional custom data that the new APIs can parse as top-level schema properties (in new schemas to be created and owned by feature/product teams that reference MP's available interaction schemas).
Using the decorator design pattern, we can create the necessary decorator classes to extend the original data object that is submitted in an event. In its initial incarnation, the Metrics Platform APIs provided the ability to include contextual attributes with events based on stream configuration. This can be readily refactored as a decorator to include specified contextual attributes per stream config. We can model custom data accordingly by providing extended submit methods that take a custom data object as a parameter and submit them as top-level properties to be validated against their corresponding schemas.
New API for submitting core interaction events can be simplified for MVP:
createEventSubmitter( streamName: string, schemaID?: string ): ( customData?: Object ) => { return submitEvent( streamName: string, schemaID?: string, customData?: Object ): void } // See example code in T343311 description submitEvent( streamName: string, schemaID?: string, customData?: Object ) submitClick( elementID: string, elementFriendlyName?: string ): void; submitClickCustom( elementID: string, elementFriendlyName?: string, customData?: Object ): void;
For each MP library, we should agree upon consistent method names and provide documentation accordingly. This is currently being determined in spike T345439.
Success Criteria
- Deadlines
- 1-2 client libraries updated by end of Sprint 01
- User satisfaction
- Client code is able to submit events using updated APIs
- Performance
- Events are submitted without increases in validation errors
- Accessibility
- N/A
- Maintenance
- As MVP, these APIs will be updated as features are included in scope
- Movement impact
- As a dependency of the centralized experimentation platform, updated MP APIs will enable informed data-driven decision-making of new features and products.
- Scalability
- MP APIs will be iterated upon to cover majority of use cases (funnel events - out of scope?, etc)
- Data Quality
- MP data will be assessed by Product Analytics to be consistent and reliable.
- Integration
- Current production instruments using MP libraries are updated accordingly.
- Compliance
- MP interactions schemas have LS3C approvals if needed.
Success metrics
- How we will measure success
- When current (or new) production instruments are using the new MP APIs to submit events.
In scope
- known scope
- PHP
- Javascript
- Java
Out of Scope
- known boundaries
- Swift
Artifacts & Resources
Relevant schema patches: