---
# System prepended metadata

title: Ideas

---

- `PDPRegistry:logMeasureSpaceTap(fromGallery: Bool, product: CatalogEntry)` has a guard clause that grabs the current dictionary, this should be moved to a helper function to simply return the optional and remove the need for casting the dictionary
- `AnalyticsManager:DictionaryFrom:307` returns a `[String: Any]` but is cast to `[String : String]`?
-

# Ideas
- Extend the `AnalyticEvent` type to have an `append(key:Value:)` function that returns self to allow easy chain along
- Use `typeAlias` in individual registries to turn things like `Keys.Analytics.Feedback.type` to `Feedback.type`
- Should objects conform to a protocol for analytics say `AnalyticsCapable` that allows an object to hold it's properties on the object (Or possibly an actor object that takes the native object and endows it with analytics properties?), this would allow for objects to merge their dictionaries for easier analytics setup. The downside is if there is a need for more than 1 analytics message from an object that that object cannot have more than 1 analytics representation. Example would be `PetProfilesRegistry:getAttributes(from:)`
- There are a lot of if/else statements, it'd be faster and easier to simply `compactMapValues` on dictionaries

# Questions
- What's the difference between the properties dictionary created in the analytic and the custom flags?
- Is there a reason to use a class vs struct for the `AnalyticEvent`s?
- Mparticle SDK offers options to set the environment, this would be useful for development and we can also disable all console logging for Mparticle (https://docs.mparticle.com/developers/sdk/ios/getting-started/#environment)
- Create an `AnalyticsWriter` for the logger to handle specifically analytics and maybe give them their own prefix

# Team Concerns
- Timing: It can seem like the timing is off sometimes in having data ready
- Multiple targets, the requirement of needing to have the platform available for all targets ecom/stickers/today widget etc.
- 