RUM Events - Forks and Roadmap

[cforce]

First of all, thanks for the fantastic work on this project — it’s really appreciated!

Following the recent OTEP #169 I’m trying to understand how this new RUM signal is expected to be supported in the Android SDK. I have a few questions I hope you can clarify:

RUM events vs Logs
Currently, the OTel Android SDK sends user interaction data (clicks, crashes, stack traces) as logs.
With the new RUM event signal defined in OTEP #169, should these interactions continue to be sent as logs, or should they use the new RUM signal type?
Is there a dedicated RUM event type in the current SDK, and if so, how can it be filtered in the Gateway?

RUM events in metrics/traces context
Some interactions could potentially be represented as metrics (e.g., crashes per minute) or traces (full stack traces).
Does the team have guidance on when to use RUM events versus metrics or traces?

SDK support / roadmap
Is there a timeline or existing implementation for RUM events in the official OpenTelemetry Android SDK?
Are there examples or configuration options (similar to TelemetryConfig.SESSION_EVENTS) for enabling or disabling RUM events?

Integration with existing pipelines
Currently, some teams fork the SDK to send RUM data to AWS CloudWatch - see aws-observability/aws-otel-android#68
How should teams integrate RUM events via OTLP for other backends, such as Datadog or self-hosted OTel collectors?
I would greatly appreciate any guidance or examples showing how RUM events should be implemented and consumed in Android apps.

Observations
I haven’t found evidence that the “official” OTel‑Android SDK includes a fully implemented RUM events signal matching OTEP 169 out-of-the-box. While the mobile events spec exists (in development), I don’t see a stable release indicating that RUM signal support is available.

Thanks again for shedding some light on this!

[breedx-splk]

Hey @cforce thanks for following the project and for the kind words!

I think there's been some misunderstanding about OTEP #169, however -- that was originally proposed in 2021 and was closed as stale more than a year ago. The rest of your issue kinda assumes that OTEP-169 was merged as spec of something...which is definitely was not. With that in mind, I think that some of the questions you raised are misguided or off-base, but that's fine, I'll try and address some of these points, because I think it's important.

RUM events vs Logs

We don't have a spec for what constitutes a "RUM event" vs. a normal OTel event. You can read more about OTel events here, but the main thing is that Events are carried on the log signal. Any log that has a non-empty/null EventName field must be considered an event (that is the primary semantic distinction). To my knowledge, there is nothing yet in the semantic convention that differentiates any event as a "RUM event", although there are several events now defined in semconv that only make sense in a client (RUM) context (like clicks or sessions, for starters).

Does the team have guidance on when to use RUM events versus metrics or traces?

Not written down yet, no...but we want to. This page here is intended to be a placeholder where such cross-client guidance can be provided. In general, metrics are considerably less useful on client apps due to the large install base + sessions causing high cardinality. There are some ideas about how to manage this and make metrics useful, but right now the guidance is simply to avoid metrics and use events for most things that are zero-duration, and possibly use spans for external calls and maybe for user actions that have a duration. Still very much a work in progress all that.

Is there a timeline or existing implementation for RUM events in the official OpenTelemetry Android SDK?

Again, not "RUM events" per se, but events are a first-class operation. On android, we provide a convenience method that wraps the sdk event capabilities. See OpenTelemetryRum.emitEvent().

How should teams integrate RUM events via OTLP for other backends

Like all OTel projects, opentelemetry-android supports OTLP as a first-class citizen out of the box. This is our default protocol for export. If you need to export in a different format or protocol, you can do that, but we don't have great docs on that yet, mostly because it's considered nonstandard now. The short version is that you can use the OpenTelemetryRumBuilder from our core module and customize portions of the underlying otel sdk.

Hope that helps! Thanks again.

[cforce]

Thanks for the clarification — that helps a lot.
That said, this discussion highlights a broader issue several of us in the community are running into when trying to adopt OTel RUM on Android.

Right now there’s no clear, first-class RUM signal — and it’s becoming a practical limitation.

Since the Android SDK (and the client-side story in general) currently models user interactions as logs or spans, it’s hard to build a consistent RUM pipeline across vendors, collectors, and mobile platforms.

A few concrete challenges we keep seeing:

1. Collectors can’t reliably detect or route RUM data

Without a typed signal or stable conventions, RUM events end up looking just like arbitrary logs.
That makes it difficult to apply things like:

• RUM-specific routing,
• mobile-aware sampling rules,
• enrichment (sessions, views, actions),
• or any kind of structured processing.
• dedictaed dashboards for mobile/rum based on otel

Everyone ends up pattern-matching on log fields differently, which leads to fragmentation.

2. Different vendors are already going in different directions

Some treat RUM events as logs, others wrap them into proprietary RUM constructs, others build their own mapping on top of OTLP.
This is understandable, but it means we’re drifting away from interoperability rather than toward it.

3. . Mobile and embedded platforms need stronger guarantees

On Android and similar environments, things like:

• bandwidth usage,
• CPU cost,
• event volume,
• and stable schemas
  are not just “nice to have.”

A lightly-typed log signal doesn’t give enough structure to optimize or enforce those constraints.

4. The community would really benefit from a clearer direction

The need that OTEP-169 aimed at is still very real: a small, well-defined, typed RUM event model that all SDKs and backends can agree on.
It would be incredibly helpful to have:

• a basic RUM event type or a clear sdk based mapping which goes beyond the current interface
• a minimal set of standard fields (event type, screen/view, session context, etc.),
• guidance on when to use events vs spans,
• and expectations for collectors (how to detect and process RUM events).

Even a simple, incremental spec would go a long way toward preventing fragmentation and making RUM more portable across the ecosystem.

Happy to help contribute use-cases or concrete requirements from the mobile/device side. And thanks again for all the work the team is putting into client-side telemetry — the progress in this area is great to see.