Member Avatar for LaxLoafer

I recently dispatched a newsletter via email. Each link in the newsletter pointed to a page on our website, and each link contained a query string that identified which newsletter a subscriber was responding to.

The query string uses Google Analytics tracking code, so the links looked something like this...

<a href="" />click here!</a>

The method has worked correctly for previous mailshots, but on this occasion something rather unexpected happened. Google Analytics captured visits to the pages that were not referenced in the newsletter, in addition to the ones that were. The raw server logs also show HTTP GET requests for other unintended pages on the site, with the query string appended.

How can this be?

The web server is IIS7 running on Windows 2008. I recently added a customized HTTP handler to serve a web version of the newsletter, which basically links in external stylesheets, JavaScript, and removes the said query string from the now internal links.

Any ideas?

  • 2 Contributors
  • 3 Replies
  • 200 Views
  • 23 Hours Discussion Span
  • Latest Post Latest Post by LaxLoafer

Dani AI

Generated

Good catch, — the spreadsheet sort explains the mismatched server-log rows. Because Google Analytics is still showing unexpected landing pages, treat that as a separate problem and run a targeted check-list rather than assuming the logs were lying.

Most common causes for GA showing “wrong” landing pages are non-human link activity or link-rewriting in front of your site: email/security scanners and gateway crawlers (Proofpoint, Barracuda, Office365/Exchange filters, etc.), ESP click-tracking redirects that wrap and then re‑emit URLs, a broken rewrite in your “web version” handler (a bad base href or global replace that tacks UTM onto unrelated hrefs), or bots crawling your links. You can usually tell them apart by looking at IIS log fields: client IP, User‑Agent, timestamp, cs‑uri‑stem and cs‑uri‑query, and the Referer. Repeated different-page hits from the same IP/UA minutes after the send = scanner/crawler. Lots of distinct IPs with real browser UAs = real users.

Practical steps to diagnose and prevent it:

  1. Don’t rely on spreadsheet sorting — parse logs with LogParser/PowerShell/Python so each raw line stays intact and you can group by c-ip, cs(User‑Agent), cs-uri-query and timestamp.
  2. Reproduce with a small test send using unique tokens (one distinct utm_content or link_id per link) and watch GA Real‑Time plus your raw logs. If the same token appears on many pages, something in the delivery/preview path is rewriting links.
  3. Trace redirects (curl -I -L or similar) to see whether an intermediate redirector strips or reattaches query strings.
  4. Check your GA view filters and the “Exclude URL Query Parameters” field and verify you aren’t firing virtual pageviews or multiple trackers on the same page.

Prevention: give each link a unique tracking token, validate archived/newsletter HTML generated by your handler, and move log analysis to a scriptable pipeline so a single sort mistake can’t break your audit trail. Thanks to for prompting the basic sanity check that led to the first discovery.

Recommended Answers

All 3 Replies

Member Avatar for JorgeM

Google Analytics captured visits to the pages that were not referenced in the newsletter, in addition to the ones that were.

Is it possible that some of the visitors where just opening a browser and typing in the URL incorrectly which would explain why you are seeing "unintended" pages being targetted?

Member Avatar for LaxLoafer

It's possible but seems unlikely to me. Sometimes visitors will attempt to guess a URL, but rarely have I seen them include a query string, at least not with seemingly consistent and valid parameters.

We've picked up around 40 instances of these unexpected URLs. I should also mention the issue doesn't appear to be browser or OS specific.

Member Avatar for LaxLoafer

Face in palm time - someone misread the raw server logs...

To view logs I often import them into a spreadsheet, as a means to quickly sort and filter records. Anyway, somewhere along the way the URLs and query strings must have been sorted separately, so they no longer match up correctly.

Google Analytics still reports unexpected landing pages for the newsletter, but suspect that's another issue.

Jorge, thanks for your contribution.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.