When replay data is received from QM Capture, where does it go?

Replay data is sent to the ingestion services - (Neutron/Nuke) - which store the data as appropriate replay files on disk before an ETL process moves them into Google Cloud Storage (GCS) for long-term access.

explain how the capture of data and replay works

When the QM script "records" a session, it doesn't send a video; it sends the "ingredients" to rebuild the page. This data hits the ingestion server, gets saved as a file, and is then tucked away in Google’s cloud storage. When a user clicks "Play" in the QM dashboard, the platform pulls these files from the cloud to reconstruct the session.

capture data - lego example

Think of Replay Data like a Lego set. Instead of taking a photo of a finished Lego castle (a video), QM sends the instruction manual and the bricks to a warehouse (GCS). When you want to see the castle later, QM grabs the box from the warehouse and rebuilds it right in front of you.

Why is Replay data stored differently than Analytics data?

Why is Replay data stored differently than Analytics data?

When analytics data is received from QM Capture, what tables does it go into?

Analytics data is initially processed by ingestion services and inserted into MariaDB or BQIO (BigQuery Input/Output) tables before being converted via ETL into structured tables within Google BigQuery.

When analytics data is received from QM Capture, what tables does it go into? - Example library

Imagine a library. When a book is returned, it first sits on a sorting cart (MariaDB/BQIO). At the end of the hour, a librarian (the ETL process) takes the books from the cart and places them exactly where they belong on the permanent shelves (BigQuery) so that anyone can find them instantly by looking at the catalog.

What is the final storage destination for analytics data used in dashboards?

Google BigQuery (BQ).

What is the first database to receive analytics data?

It is inserted into MariaDB or BQIO tables.

What is the Hyperlane process and how does it function?

Hyperlane pulls raw session and event data from the io_data and Big Table tables in Google BigQuery. It summarizes and compiles this data into "live" data tables, which the Quantum Metric UI then queries to display real-time metrics and dashboards.

What is the Hyperlane - stadium example

Imagine a stadium scoreboard. The Raw Data (io_data): Every single ticket scanned, every hot dog sold, and every play made is recorded individually. Hyperlane: This is the logic that quickly adds up those thousands of individual events to change the score on the giant screen. Without it, you’d have to wait for someone to manually count all the paper tickets before you knew the score.

How can you identify if something is a QM Ingest defect or a QM Capture defect?

You identify the source by checking where the data "disappears": - if the data is missing from the network requests in the browser, it is a Capture defect; - if the data is successfully sent but missing or corrupted in the UI/BigQuery, it is an Ingest defect.

How can you identify if something is a QM Ingest defect or a QM Capture defect? - Restaurant App

- Capture Defect: You tap the screen to order a burger, but the tablet screen is frozen or the "Order" button doesn't respond. The kitchen has no idea you’re even hungry because the request never left your table. This is a Capture issue (the source failed). - Ingest Defect: You tap "Order" and the tablet says "Order Sent!" You wait an hour, but the burger never arrives. You check the kitchen and find out the printer ran out of paper or the chef dropped your order ticket. The kitchen received your request, but failed to turn it into a meal. This is an Ingest issue (the processing failed).

What is a common sign of an Ingest defect?

You see "Successful" (200 OK) network requests leaving the browser, but no data appears in the QM Dashboard.

How does Browscap function within Ingest?

Browscap functions within Ingest by analyzing user agent strings and adding relevant browser and device information to the incoming data, thereby enriching the data and providing valuable context for analysis. An example - We don't technically capture the browser version. We capture the UA, and ingest converts it to the "other/simpler" forms