starting point for defining key events for mobile

[bryce-b]

• [x] Create PR as draft
• [ ] Approval by at least one other agent
• [ ] Mark as Ready for Review (automatically requests reviews from all agents and PM via CODEOWNERS)
  • Remove PM from reviewers if impact on product is negligible
  • Remove agents from reviewers if the change is not relevant for them
• [ ] Merge after 2 business days passed without objections \ To auto-merge the PR, add /schedule YYYY-MM-DD to the PR description.

[apmmachine]

:green_heart: Build Succeeded

the below badges are clickable and redirect to their specific view in the CI or DOCS

Expand to view the summary

#### Build stats * Start Time: 2023-03-31T04:23:00.028+0000 * Duration: 3 min 1 sec

[bryce-b]

Some questions I have about the high level events:

• Are ANRs are type of crash, or are they recoverable? If they are recoverable, should an additional crash event be created when it isn't recovered from, or should it be one or the other: (An ANR event when it's recovered from, and a Crash event when it isn't)
• do we need to differentiate between Application lifecycle events and app opens?
• related to the above item: do we want individual event for application lifecycle events, or do we want unique events per type of lifecycle transition?

[LikeTheSalad]

Some questions I have about the high level events:

• Are ANRs are type of crash, or are they recoverable? If they are recoverable, should an additional crash event be created when it isn't recovered from, or should it be one or the other: (An ANR event when it's recovered from, and a Crash event when it isn't)
• do we need to differentiate between Application lifecycle events and app opens?
• related to the above item: do we want individual event for application lifecycle events, or do we want unique events per type of lifecycle transition?

• ANRs aren't a crash, though they can close the app if the users choose to do so when prompted with the options to either wait a bit longer, or terminate the app right away (it's very similar to when a web browser's tab isn't responding). So I don't think an additional crash event is needed, however, it seems like we still need to provide the blocked thread's stacktrace, similarly to crashes.
• I remember needing to provide "app opens" info as events, but not lifecycle events (I'm fine with sending all, it's just that I don't recall having to provide lifecycle events for now) those also seem to overlap in some scenarios with the "app opens" events, which I'm not sure if it's an issue.
• If we end up sending lifecycle events, I think it'd be better if each transition has its own event.

[bryce-b]

An interesting new development in Otel semantic conventions: https://github.com/scheler/opentelemetry-specification/blob/rum-events/specification/logs/events/semantic_conventions/browser.md

They are recommending that event attributes be nested in another kvp event.data. I think the idea behind this is to provide a namespace for event attributes to prevent them being overwritten by custom attributes.

[bryce-b]

closing this issue since it's no longer active, and relevant items were opened in separate issues.