Investigating a traffic spike with Vercel Analytics and first-party events

A traffic spike on a small website can be surprisingly difficult to explain.

On October 28, my text graphics tool, GummyType, received a sudden increase in visits. I hadn't run a campaign or a batch test.

I used three sources to investigate:

• Vercel Web Analytics.
• First-party event records stored in Upstash Redis.
• Vercel request logs and firewall data.

Each answered a different question.

1. Separate visitors, sessions, events, and requests

A Vercel snapshot showed 111 visitors and 236 page views over the previous 24 hours.

My event logs covered a separate, narrower window: approximately 17:32–17:53, Beijing time.

That window contained:

These numbers describe different things.

My session ID is stored in sessionStorage and expires after 30 minutes without a recorded event. It isn't a persistent identifier for a person.

Likewise, CDN requests include resources such as images and scripts. Thousands of requests don't mean thousands of visitors.

2. Read “direct” as missing attribution

My source classification includes this check:

if (!referrer) return "direct";

That is the meaning of direct in my implementation: no referring page was available when the session started.

It doesn't identify a channel.

A copied link, an app opening a URL, or automation navigating directly could all produce missing attribution. The label alone cannot distinguish them.

3. Check browser information separately

The strongest additional clue came from Vercel's browser breakdown.

A later snapshot classified 44 visitors, approximately 40%, as using WeChat.

Two sampled homepage requests contained different WeChat versions in their user-agent strings:

MicroMessenger/8.0.62
MicroMessenger/8.0.79

This supported WeChat usage as an explanation for part of the traffic.

It did not reveal the original message, group, or article. User-agent information is also a clue rather than proof of a human visitor.

Browser type and referring source answer different questions. A visit can be classified as WeChat in one report and direct in another without contradiction.

4. Separate suspicious browsing from attack evidence

Some sessions switched pages rapidly. One recorded 17 page views in roughly a minute.

The firewall also showed requests for paths such as:

/.env
/wp-admin/install.php
/phpinfo.php

Those probes were suspicious, but I couldn't establish that they belonged to the same activity as the analytics spike.

At the time I checked server health, Vercel reported 0% function errors and 0% timeouts.

Another distinction matters here: several GET requests close together can include framework prefetching. They don't necessarily represent someone viewing every requested page. Client-side page-view events provide different evidence.

5. Identify what the instrumentation cannot answer

My export flow records an attempt ID across stages such as:

png_export_started
png_generated
png_export_completed

That helps distinguish an export attempt from a page visit.

However, ordinary text edits and style changes weren't fully tracked. A session with one page-view event could still have spent time experimenting without exporting.

Also, a completed export event reports the browser delivery outcome. It doesn't independently verify that a file was saved to disk.

The conclusion remains incomplete

I found evidence of WeChat visits, rapid browsing, and unrelated-looking vulnerability probes.

I did not find enough evidence to label the entire spike as organic growth or an attack.

The next useful instrumentation step is a once-per-session interaction event for the first text or style edit, without collecting the user's text.

That would make the funnel clearer:

Page opened → Tool edited → Export completed

The investigation helped me narrow the possibilities. It also exposed where my data stops being able to answer the question.

Disclosure: I used AI assistance to analyze the data and draft this article. The figures describe snapshots collected on October 28, 2026.