Skip to content

Bringing back and cleaning up user_agent #235

@webmat

Description

@webmat

Early versions of ECS had user_agent more or less as the Ingest Node UA parser happens to output it's parsing, slightly renamed (see it here).

We've taken it out for Beta 1, to give ourselves some time to review its semantics and re-introduce it the right way.

Previously, the field set covered:

  • user agent / browser information: name and version (as 3 fields major/minor/patch)
  • device information: name and version
    • Note that according to the description of user_agent.version, the field was for the device version, not the user agent version. This is unintuitive. Also, it doesn't look like the IN UA parser actually emits this value, at this time.
  • operating system information: name and version fields

Looking at https://www.whatsmyua.info/ or https://www.neutrinoapi.com/api/user-agent-info, we can see the result of parsing user agents by a few different libraries. We don't need to support all of this, but it's a good review of some of the concepts encapsulated in a user agent:

  • Agent type (desktop vs mobile vs feed reader, robot, etc)
  • Agent name and version
  • Device name and version
  • OS name and version
  • CPU architecture (e.g. 64 bits)
  • Rendering engine name and version (e.g. WebKit/537.36)
  • Producer of the user agent (e.g. Google, Mozilla)
  • Screen dimensions

I'm proposing we re-introduce user_agent as basic as it was, but a bit better structured. This will give us "room to grow", so we can support more categories of information eventually.

Proposal:

user_agent:
  type: broad category of the agent (see above definition)
  name: name of the agent
  version: full version string of the agent
  device:
    name: name of the device
    version: version of the device
  os: (the reusable field set)

Caveats:

  • Currently ingest node / user_agent doesn't give us full version strings, we'll have to reconstruct from major/minor/patch, which will be imperfect in some situations

Future:

The above proposal leaves room to add other sections such as "engine", "screen" and "architecture", if we deem it necessary.

Metadata

Metadata

Assignees

Labels

Type

No type
No fields configured for issues without a type.

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions