E-commerce
August 26, 2026
Are you wondering how to spot the six essential tracking logs that trace every customer request, even when your dashboard seems to indicate success? The key lies in understanding that your logs are not a single file, but six distinct registers linking invisible failures to root causes. Knowing how to identify them is crucial for diagnosing why an order failed without ever alerting your traditional analytics.
Indeed, a failed request can stop at any level of your technical stack, invisible to your traditional tracking tools if the JavaScript does not load. This problem often occurs because no unique identifier links the six files together, making investigation impossible without a precise log configuration.
So how do you identify the six customer request tracking logs? On the agenda:
Why does your store have only one file when it actually uses six?
What are the specific roles of each level of the technical stack in tracking?
Why do application logs often overlook critical order failures?
How do you distinguish a server error from a database problem?
Which fields should you add to your logs to link all requests together?
Let's get started.
Summary
Why does your store have only one file when it uses six?
It is common to imagine that monitoring your site boils down to a single, centralized data stream. This vision is misleading because your online store does not have just one server log. It manages six different ones, and each records a distinct part of the same customer request. The fundamental question is therefore not simply what you should log, but rather which specific failures you need to be able to explain after the fact.
Take the typical example of a customer who claims that the checkout page suspended their credit card without ever capturing the funds. Your synthetic monitoring probe indicates that the site was available all day and remains green. Yet, no one can say at which precise level the request stopped. This is because no single file contains the entire journey and no shared identifier links the six logs together.
It is therefore imperative to distinguish these six layers to reconstruct a user's complete journey. These levels correspond to the CDN or edge zone, the web server, the application itself, the database, external calls to payment and delivery services, and finally internal site searches.
Each level writes its own record with its own timestamp. A request that fails at a given level may simply be absent from the next. It is this fragmentation that creates the illusion of normal operation while critical transactions are lost in the caches of your infrastructure.
Convert over 2,000 customers on average per month with Qstomy.
The world’s 1st Shopify AI dedicated to customer conversion
Empowering 200+ e-commerce merchants
What are the specific roles of each level of the technical stack in tracking?
To properly track your requests, you must understand what each tier records and which unique question it is the only one capable of answering. The first level is the CDN or edge zone. It records cached, blocked, or limited requests before they even reach your origin. Its unique question is: did this request ever reach our infrastructure?
The second level is the web server, such as Nginx or Apache. It writes a single line per request indicating the path, the response status, and the processing time. It answers the question: what did the server return and how quickly? This is your first line of defense for measuring raw responsiveness.
The third level is the application itself. It validates the shopping cart, records created orders or failed validations, and notes payment declines. It answers the crucial question: which order failed and on which business rule? This level is vital for understanding your site's logic.
Other levels complete this picture. The database flags slow queries or lock conflicts. Outbound calls to third parties, such as payment gateways, record the actual responses received. Finally, the internal search engine captures what shoppers typed and whether they found no results.
Why do application logs often forget critical command failures?
One of the major pitfalls in e-commerce is the confusion between access logs and application logs. Basic logs like the Common Log Format (CLF) or the combined format only record HTTP traffic, without understanding the underlying business logic. That is why a store can have logs showing that all requests received a 200 OK response, while completely ignoring that some orders failed.
Application logs are designed to record business events rather than simple network traffic. If your configuration does not explicitly capture these business events, such as a cart validation failure or a payment rule failure, you will lose track of the actual failure. Thus, a store can log every HTTP request and remain blind to which order actually failed.
This means that monitoring only HTTP statuses is insufficient to guarantee the reliability of your transactions. It is essential to enable application event logging to see beyond the simple HTTP response code and understand the true causes of disruptions in the customer journey.
How to distinguish a server error from a database problem?
Confusion between a network slowdown and a data bottleneck is common during incidents. The application layer queries the database to retrieve shopping cart information or validate stock. This is when the database layer can generate its own logs.
Slow query logs and connection error or lock-wait reports help identify whether the delay stems from data processing. Without these specific logs, it is difficult to know whether the slowness is due to the web server failing to process a request or the database taking too long to respond to it.
To clearly distinguish between the two, one must examine the performance indicators specific to each layer. If the processing time on the application side seems normal but the action is blocked, it is often a database issue. Conversely, if the request reaches the top of the stack but fails to be processed, the problem is likely network or application-related.
Which fields should you add to your logs to link all requests together?
The default logging format on most Nginx and Apache installations, called Common Log Format or Combined Log Format, rarely records the three essential elements needed to reconstruct an incident: the request duration, what the upstream server returned, and the unique identifier that survives across all levels.
Three specific fields decide your ability to reconstruct a failure after the fact. First, you must add an explicit identification for each request, often in the form of an X-Request-ID header generated at the edge and written at every stage. Without this common identifier, it is impossible to correlate the six logs.
Additionally, you must distinctly log the overall request duration and the upstream response time. This allows you to distinguish your own internal queue from a slowdown caused by a third-party service. Finally, record the upstream server status alongside the status sent to the client, as a gateway may transform a 502 into a custom error page logged as a 200.
Why are internal search logs often neglected and yet essential?
Internal search logs on your site are one of the most frequently missing or poorly collected levels, although they are vital for understanding user behavior. This level captures what buyers typed in the search bar and how many results they found.
These logs answer a specific question: what did shoppers ask for and what did they not find? If you see a high number of searches with no results or with very long response times, this immediately indicates a problem with your product indexing or your search engine performance.
Neglecting these logs means depriving yourself of a fine understanding of customer intent. You may know that the access page is stable, but if users never find what they are looking for via the search bar, your conversion rate will be impacted without this appearing in your traditional sales statistics.
What is the difference between server logs and JavaScript analysis like GA4?
It is fundamental to understand that server logs and JavaScript analytics tools like Google Analytics (GA4) answer different questions. JavaScript analytics records what was successfully executed by the client's browser, whereas server logs record what was actually requested from the server.
The requests that matter most during an incident are precisely those that JavaScript analytics never sees. Client-side collection requires the page to render and the script to execute. If a request returns an HTTP 5xx code, times out, or is cut off in mid-processing, no event will be sent to your analytics tools.
Furthermore, a client who rejects the consent banner or blocks the script with an ad-blocker will generate no data in your analytics tool, even though the server will have successfully received and processed their request. Logs therefore also capture traffic generated without a browser, such as web crawlers, scrapers, API clients, or autonomous shopping bots.
How to manage customer IDs for accurate traceability?
Identifier management is the key to effective traceability. You must distinguish between two types of identity: the session identifier and the request identifier. The session identifier answers the question "which client is it?", while the request identifier answers "which attempt failed?".
On an e-commerce site, it should be noted that the client's IP address in the first position in the logs may be that of your own gateway (CDN) and not of the actual shopper. It is therefore crucial to configure the web server to read the X-Forwarded-For header to obtain the actual IP address.
In addition, you must write the timestamps in UTC in an ISO 8601 format. This allows data to be sorted and compared between different levels arithmetically and without temporal ambiguity. The use of a unique identifier generated at the beginning of the journey (X-Request-ID) is non-negotiable to link all these pieces of an investigation.
What risks does the standard logging format pose for e-commerce?
The default combined format on most web server installations is insufficient for the advanced needs of modern e-commerce. It contains the seven fields of the common format and two more: the referrer and the user agent. However, it lacks the three critical elements for diagnosis.
A typical example shows an anonymized line with no indication of overall request duration or specific upstream status. If your edge server receives a 502 from the origin server but returns it as a custom error page with a 200 code, you will lose track of the actual failure by analyzing only standard HTTP statuses.
This is why it is imperative to customize your logs to explicitly include the request duration and the upstream status. This allows you to see not only what was sent to the client, but also how your internal infrastructure actually handled that request. Configuring these missing fields must be done even before deciding where to send the logs.
How to interpret the logs for exclusive offers and in-store pickup?
Your site's logs are particularly useful for answering specific questions related to your sales channels. For example, if you offer exclusive web deals, the logs can reveal how your customers interact with these products that cannot be found in-store. You can then analyze the requests to these pages to detect availability or pricing issues.
Similarly, for in-store pickup (click and collect), it is essential to track interactions related to this option. If you do not have a dedicated application, your logs must capture pickup requests and the associated validations. This allows you to manage customer queries regarding in-store availability without relying solely on external tools.
This type of detailed analysis also helps you understand how customers react to web deals that are not physically available, or how they manage online-exclusive products. By linking these logs to your customer support policy, you can improve the overall experience and respond more effectively to specific user inquiries.
How does Qstomy help optimize data collection and tracking?
Qstomy, your expert Shopify AI agent, completes this technical infrastructure with a capacity for direct action on data. Unlike a simple monitoring tool that merely alerts you to a problem, Qstomy steps in to resolve the situation or improve the customer experience in real time.
As a guide to purchasing and a tracking expert, Qstomy analyzes data flows to identify cross-selling or upselling opportunities. It optimizes parcel tracking and after-sales service (customer support) management by centralizing relevant information.
Unlike logs that merely record failure, Qstomy uses this data to take action. It can generate personalized recommendations, manage customer support policies for agents, and help you track the overall performance of your store in relation to your margin and visibility goals.
What checklist should be applied before enabling full log tracking?
Before setting up comprehensive monitoring, it is vital to follow a rigorous checklist. Start by enabling internal search logs and ensuring they capture queries without results.
Next, verify that the unique identifier (X-Request-ID) is generated at the start of the journey and propagated to all six levels of the stack. Also, ensure that time stamps are synchronized in UTC on each layer to facilitate sorting.
Finally, explicitly configure the duration of queries and the upstream status in your logging formats. Without these elements, you will continue to see your dashboard as green while your transactions fail. The key is to log what matters before deciding where to send the data.
To go further: E-commerce conversation analysis: understanding real customer questions - Qstomy, E-commerce support policy: writing clear rules for customers and agents - Qstomy, How to handle customer questions about web offers not available in store - Qstomy, What is Google Shopping for e-commerce? Definition, feed and value for a store - Qstomy, E-commerce Analytics: what to track and why? - Qstomy, E-commerce CRM and customer support: using the right data to respond better - Qstomy, How to handle customer questions about in-store pickup without a dedicated app - Qstomy.
Enzo
August 26, 2026
