There once was a tool with a feature
The merits of which like a preacher
I praise on this blog
And I’m almost agog
For it’s part of my normal procedure
I have mentioned Charles before, but today I want to show you my two most common use-cases.
Track the Tracking
Charles sits between the browser and the Internet as a proxy. It muscles itself in automatically when you launch it, so no messing around with proxy settings is needed.
Once started, it can show a structural view (“Structure”) or a timeline (“Sequence”).
A lot of people use the structural view but I am a big fan of the timeline, mainly because it is better suited for troubleshooting or checking work in progress.
Here’s what I do:
- Switch to “Sequence”
- Add a filter (e.g. “/b/ss”) so I only see the traffic I’m interested in
- Select the “Request” tab where I can see the URL parameters spelled out individually
Looks like this:Some things I do when I use Charles:
I use the “Request” tab, “Query String” sub tab, to see what “variables” the tracking call contains. In the screenshot, we see
s.pageName (set to “home”), some events, props and eVars. We even see some Dynamic Variables (eVar11 will have the same value as prop11, and prop14 will contain the contents of the s_vi cookie).
Trick the Tracking
Here comes the ultimate killer feature for anybody who builds for or works with anything on the WWW: “Map Local”.
My top use case: modify the s_code.js file and see the results in the live environment.
This is useful in a lot of situations.
- When you want to upgrade, add or remove a plugin
- When you want to test Campaign tracking, maybe with live campaigns or paid search
- When you want to troubleshoot, maybe start with a simplified version of the s_code.js file
So how does it work?
First you download whichever file it is that you want to work on from the web site and store it locally. Next, you tell Charles to serve the local file rather than the original. Then, you alternate between your editor and the browser, making changes and checking them.
The great thing about this is that the browser has no idea what is happening. “Map Local” is completely transparent!
So, go to Tools > Map Local (or simply press Ctrl+Shift+L) to call up the Map Local Settings dialog.Click the “Add” button to add a new mapping or double-click an existing mapping to edit it. The Edit Mapping dialog window appears. In this dialog, you specify what exactly you want to map, and what file to use instead.
You can leave some of the fields empty. As an example: if the “Protocol” field is set to “http” Charles will only map files served via
HTTPS, but if you leave the “Protocol” field empty, it’ll match both. The same goes for the “Port”, “Query” and even the “Path” field. Careful with the latter!
Close both dialogs and you’re good to go.
A simpler way of adding a “Map Local” to a remote file is via the Structure or Sequence view.
Just find the file, right-click it, then select “Map Local…”Note that if the file is mapped already, Charles displays a helpful tick mark next to it!
Charles is not the only proxy out there, of course. You can achieve the same using Fiddler, I’m sure.
Pro tip: when you’re done developing and testing, make sure you disable “Map Local”!
I can assure you that by the next time you are looking at something, you’ll have forgotten all about it, and you will see inexplicable effects and a live s_code.js file that looks old, even though you’ll be sure IT just pushed live the latest version. You’ll curse browser caches, proxies and — oh, wait a tick … proxies … d’uh.
Happened to me more often than I’m prepared to admit.
This one goes out to Karl!