On Monday, a small shop publishes a new collection page. On Tuesday, it sends a newsletter. Wednesday’s traffic chart climbs. By Friday, visits are back where they were. In the moment, the owner knows what happened that week. A month later, the chart is still there, but the context has scattered across an email draft, a release message, and someone’s memory.
The familiar question follows: "Why did traffic jump?" A chart can show the timing and size of a change. It cannot, by itself, tell you whether the newsletter, the page update, a mention elsewhere, or something unrelated brought people in. A short annotation on the date gives the next person a place to start. It also gives your future self a more honest answer than "I think we did something around then."
Chart annotations are useful for ordinary teams precisely because they are small. You do not need a formal incident report for every bump in visits. You need enough context to make a later review fair: what changed, when it changed, and what you knew at the time.
The chart shows the movement, not the reason
Traffic is affected by many things you control and many you do not. A new page, email, discount, ad, social post, or site release can change what visitors see. Search visibility, a partner mention, a holiday, or an outage can change the pattern too. Several of those events can land on the same day.
The line on the chart records an outcome. Your team supplies the timeline around it. An annotation is a dated note attached to that timeline. In Hitsteps, you can mark a promotion, deployment, outage, or general note on a date-based traffic chart. The mark appears on other date-based stats charts for that site, so context written while looking at one view can help when you open another. Clicking a chart point gives you an option to annotate that date.
That shared context matters when a question moves between people. The person who sent the email may know its subject and audience. The developer may know exactly when a change went live. The owner may remember a customer complaint. If each person adds the small fact they know, the chart becomes easier to discuss without making any one person reconstruct the whole week.
An annotation is evidence of an event, not proof of its effect. "Newsletter sent to existing subscribers" is a useful fact. "Newsletter caused all new traffic" is a much larger claim. Keep the note close to what you actually know.
Make a note that will still make sense later
A good annotation can be read in a few seconds by someone who was not there. Use a simple pattern: action, scope, and any detail needed to check it later. For example:
- Deployment: "New booking form published at 10:30. Replaced the old form on /book."
- Promotion: "Autumn collection newsletter sent to subscribers. Main link went to /autumn."
- Outage: "Checkout was unavailable after a payment provider error. Restored after the provider recovered."
- General note: "Local newspaper linked to our winter guide. Link found during Thursday review."
To make one in Hitsteps, open a date-based chart, click the relevant point, and choose the option to annotate that date. Pick the kind that fits the event, write the short explanation, and save it. If you have edit access, you can return to the Annotations page under Dashboard to correct or remove a manual note later. The useful habit is to add the note near the event, while the timing and scope are still easy to check.
These are examples, not a request to fill every note with technical detail. A small service site might need the exact page path; a store might need the offer name; an agency might need the client and the person responsible. If a URL, campaign name, or release reference will help someone verify the event, include it. Leave out customer names, email addresses, and other personal details.
Use the date the event affected visitors, not merely the date someone noticed it in a report. If it began late at night or crossed into another day, put the relevant time and timezone in the text. Manual notes are tied to dates; Hitsteps’ hourly charts show items with an exact event time, while day-level notes stay on date-based charts. A precise time in your note helps a human investigate without turning a day note into an hourly measurement.
Start with the release that changed the site
A release is a strong candidate for annotation because it creates a clear before and after question. Imagine a service business replaces its contact form on a Wednesday morning. On Thursday, visits to the contact page look steady, but enquiries seem quieter. Without a release note, the team may spend its first hour debating whether the chart is unusual. With one, it can test the form, check the confirmation path, and compare the affected period with the usual pattern.
Write what shipped, where, and when: "Contact form update published on /contact at 09:40. New confirmation page enabled." If the change is rolled back, add that as a separate note on the rollback date. Months later, the two notes will show the sequence. If several small fixes were bundled into one release, name the customer-facing change rather than pasting a long changelog into the chart.
A release and a traffic move on the same day may be related, but the timing alone does not settle it. A landing page can receive more visits because a campaign started. A form change can affect submissions without changing the number of arrivals. Use the annotation to choose the next check, such as opening the page, testing the form, or looking at the traffic source. The note saves the team from forgetting the release; it does not do the investigation for them.
Give campaigns and newsletters their own place on the timeline
When an email goes out, note the send date, its purpose, and its destination. "October newsletter sent at 08:00 to subscribers; featured the new collection and linked to /autumn" is much more useful than "email." If a reminder went out two days later, mark that separately. A later chart may show two waves, or it may show very little. Either result is easier to discuss when the sends are visible.
Do the same for paid or partner campaigns. Record when the campaign actually began serving, the audience or placement if that matters, and the landing page. If the ad was paused, the budget changed, or a partner moved the link, add a new note. A campaign name alone is often too vague because a campaign may run for weeks while its page, creative, or targeting changes.
Annotations and tagged links answer different questions. The note says what your team did and when. A tagged link can help identify visits that arrived through a link you controlled. If you use UTM tags, keep the campaign label consistent and refer to it in the note so someone can match the launch to the report. The UTM guide has a practical naming system for those links. Neither a note nor a tag proves that every later visit or sale came from the campaign.
For a small team, the aim is a short, readable event trail. Mark the launch, meaningful changes, and end of a campaign. You do not need a dot for every ad edit if those edits will not help you answer a later question.
Mark outages as part of the traffic story
Suppose a store’s visits fall on a Saturday afternoon. It is tempting to ask whether the weekend audience disappeared. But the checkout page may have failed, the site may have been unreachable for some visitors, or a tracking change may have interrupted the count. An outage note changes the first question from "Why did people lose interest?" to "What was available, and what was measured?"
Record the affected path, the observed start and recovery times, and what confirmed the problem. "Checkout entry failed for customers from 14:20 to 15:10; homepage remained available" is clearer than "site down." If only one page or one region was affected, say so. If the scope is still uncertain, say that too. A chart note should not make an incident sound broader than the evidence supports.
Hitsteps can show confirmed down and recovered incidents from uptime monitors as chart marks when the monitor is set to show them as annotations. That can place an operational signal beside traffic. It still helps to record a brief human note when the incident needs context, such as a broken checkout path that a generic homepage check would miss. The uptime guide covers how to choose useful checks and respond to them.
Remember that an apparent traffic drop during an outage can reflect two different things. People may not have been able to reach the site, and tracking may not have recorded activity while pages failed. The chart alone cannot separate those possibilities. Check the monitor history, the affected page, and whatever other records your team has before estimating the impact.
Write down what you do not know
Not every jump has a known cause. A post can be shared in a private group, a search result can change, or several small sources can rise together. If the team cannot explain a spike after a reasonable check, it is fine to say so: "Traffic rose on Thursday. No campaign or release found in the team calendar. Check referrals and search again next week."
That note has a purpose. It prevents the next person from assuming nobody looked. It also gives the team a point to revisit if another clue appears. If you later learn that a local organization linked to your guide, edit the note or add a follow-up with the evidence. Avoid filling the gap with a confident story just because the chart looks dramatic.
For drops, check whether the measurement itself changed. Was tracking installed or removed on a page? Did a redirect change? Did the site fail to load? Did the date range or weekday mix change? Hitsteps can place automatic annotations for some tracking and settings changes on eligible sites, but a manual note about a known change is still useful when the details matter to your team. A drop in recorded visits is a prompt to investigate; it is not automatically a drop in demand.
Read the days around the mark
Once the event is marked, compare the pattern around it. Look at the days before and after, but choose a fair comparison. Monday often behaves differently from Saturday. A newsletter sent during a holiday may be surrounded by an unusual week. A new campaign may take time to reach people, and an outage may affect only part of a day.
The Hitsteps Annotations page includes before and after impact views for people’s annotations. Its comparison uses the same weekdays from an earlier period, which helps avoid treating an ordinary weekday pattern as a change caused by the event. You can reach the Annotations page under Dashboard and review your manual notes there, including editing or deleting them. Treat the comparison as a useful prompt to inspect the chart, not a verdict on causation.
Ask three questions as you read:
- What moved? Look at the traffic measure and the size and length of the change. A brief peak is different from a sustained shift.
- Where did it move? Check the page, source, or audience that should have been affected. A newsletter to a collection page should lead you to inspect that page and the relevant arrival paths.
- What else changed? Read nearby annotations, the team calendar, campaign records, and uptime history. A release and an email on the same date need separate consideration.
Write a conclusion in the language the evidence supports. "Visits to the collection page rose after the newsletter send" describes an observation. "The newsletter caused the increase" needs more support. For a small site, modest wording is especially useful because a handful of visits can make a line look dramatic.
When several things happen on one day
Real weeks are messy. The owner sends an email while the developer publishes a page fix and a partner shares a link. The chart may show one dot for a day that holds several annotations. Open the mark and read the items rather than relying on its color as the entire explanation.
Keep separate notes for separate events. "Newsletter sent" and "pricing page changed" should not become one vague entry called "marketing updates." Separate entries let the team see that there were competing explanations for a change. They also help a new colleague ask the right person for details.
If you can, stagger major changes when you need a cleaner comparison. A small team cannot always do that, and it should not delay an urgent fix to protect a chart. When events overlap, simply record the overlap and be more cautious about attribution.
Let automatic marks start a conversation
Manual notes capture the things your team knows firsthand. On eligible Hitsteps sites, automatic annotations can also add context such as traffic spikes and drops, first-seen pages or campaigns, tracking and settings changes, and selected calendar events. Automatic annotations are included on Pro and above and during eligible trials; manual chart annotations remain available across plans. Uptime incident marks follow the monitor’s annotation setting.
These marks are helpful prompts, especially when nobody thought to write a note. A traffic spike annotation tells you that the pattern stood out under the detection rule. It does not know the conversation that happened in your office or what a visitor intended. A first-seen campaign mark tells you when that label appeared in the available tracking, not why people responded.
Use a quick review: open the mark, read its details, check the surrounding chart, and ask the person closest to the event what happened. Hitsteps lets you keep some automatic findings as notes or dismiss them when they are not useful. The point is to leave a timeline your team can trust, with human context added where the automatic mark cannot supply it.
A small habit that makes the next review easier
You do not need to annotate every wobble. Start with a handful of events likely to matter later: releases, newsletters, campaign launches or pauses, outages, major content changes, and measurement changes. Give someone responsibility for each kind of event. The person who sends the email can mark it; the person who publishes the site can mark the release; the person who handles an incident can record its scope.
A practical weekly routine can be short:
- Open the traffic chart and scan for jumps, drops, and existing marks.
- Compare it with the team’s calendar, releases, sends, and incident notes.
- Add or correct annotations while the facts are still easy to verify.
- Pick one unexplained change worth investigating, and write down what you checked.
- Share one plain-language observation and the next action with the team.
If a note turns out to be wrong, correct it. If a campaign launch was scheduled for Monday but actually started Tuesday, use Tuesday. If an outage affected only checkout, narrow the description. Accuracy matters more than filling every date.
A chart with a few clear notes gives a small team a shared memory. The next time someone asks why traffic rose or fell, you can start with the actual sequence of events, test the likely explanations, and say clearly where the evidence stops.
