About

Software Telemetry technology has been developed a lot for software developing industry. So will the Customer Journey Industry.

My working experiences on Software Telemetry in a Customer Digital Journey Analysis company has given me a new vision on what’s the future be like for Digital Journey Industry.

The same thing in two different ares

Software Telemetry is a kind of process where you implement various tools to collect software runtime data such as logs, metrics and traces. These data, with proper processing, can generate useful information or insights about applications’ real-world performances. So that you can use them to improve your application.

Customer Digital Journey Analysis, on the other hand, collects real-world users experiences while using their product. In Auryc’s World that includes: what they see (DOM mutations or screen-shots of the app) what they do (user interactions like clicks, types, scrolling, mouse over etc.) what happened (API calls, console logs) and what they think (Submitted Feedbacks). With these kind of data Auryc can help website owners to understand the real-world performance of their website and spot actionable items to improve their websites.

Find similarity here? Actually they are exactly same thing in the two area — using Telemetry to measure how a thing (program or a software) works in the real world. The key idea is — You can’t improve what you don’t measure.

Thus the mission of the industry is trying to solve the observability issue with 3 questions in mind:

• What to collect ?
• How to collect those data ?
• How to make use of these data ?

How Software Telemetry solves the challenge

I want to first talk about how OpenSource world, especially OpenTelemetry Project (OTEL for short), tries to solve the software Telemetry issue in brief. Then talk the Digital Journey Industry in details.

What to collect: the signals

When comes to the first question. I want to borrow the concept form OpenTelemetry project. OpenTelemetry is structured around signals, or categories of telemetry. Metrics, logs, traces, and baggage are examples of signals. Each signal represents a coherent, stand-alone set of functionality.

• Log is the most basic kind of telemetry data. It can be generate with programs output. It’s usually unstructured or semi-structured text data. Log can gives use rich information on what had happened at a exact point of time in a narrowed context. But it’s usually hard to generate high level insights from log directly.
• Metrics are a specific kind of telemetry data. They represent a snapshot of the current state for a set of data. Contrary to metrics, singular events occur at a specific time. Metrics tend to aggregate data. While this can lose information, the reduction in overhead is an engineering trade-off commonly chosen in many modern monitoring systems.
• Traces track the progression of a single request, called a trace, as it is handled by services that make up an application. The request may be initiated by a user or an application. Distributed tracing is a form of tracing that traverses process, network and security boundaries. Each unit of work in a trace is called a span; a trace is a tree of spans.

You can find more comprehensive introduction to each signal here. https://opentelemetry.io/docs/concepts/data-sources/

How to collect: the protocols & collector