The quick 360.
The cat is alive.
A stateless web can be a good thing, but sometimes you need to know what Ahsheed & Inge are up to as they travel through your site.
When we don't know, we end up with Schrödinger's Website, a situation in which our site & our client relationship are alive and dead at the same time.
Sometimes we need to track...
- Which partner referred this visitor to my site?
- Has this visitor visited /secret-page yet?
- Did we show that pop-up already?
- Did they submit that form?
Cookies aren't evil...
...and they're especially delicious with milk.
Cookies v. web storage
What's the difference? Which should I use?
Cookies were invented first, as a means to pass text key-value pairs between the server and the browser, and for the browser to remember them.
This made much of the web possible, including logins & referral tracking. But it also came with abuse and a megaswarm of ad trackers.
Web Storage was invented later and is based on a similar concept, but with slightly different goals.
Here are some of the key ways web storage differs;
- It's client-side only. Nothing is passed to the server. Web Storage is used for scripts to store and retrieve application state.
- Unlike cookies, web storage does not have a built-in date-of-expiration feature. It either expires as soon as the tab is closed [ session-storage ] or effectively never [ local-storage ].
- There are different security rules in effect, to deal with modern requirements.
- Better support for object storage.
- Much larger storage capacity.
- Much cleaner interfaces, with native js code support.
Web storage was just so... clean. It was all we needed.
This demo currently focuses on web storage, but if you look at the underlying user-tracking library, you can easily change that to cookies as well.
Whoa, Cool!
But... what is the point of tracking?
How to I show or hide things on the site, based on what the visitor has done?
In this demo, we're using WFU's new webflow-track.js library, which means hiding and showing things is as simple as adding a custom attribute.
Have a look at the page & site source code to see how the different events are tracked;
- Clicking an element, like a button
- Visiting a specific page
- Entering the site with a referrer ID on the URL
Look at the elements in the Tracking Status section above in order to see how the custom attribute is applied.
Say it with me.
This is NOT security.
Sure, you can hide stuff...
Sure, you could even build a pseudo-login system...
But that data is still there, waiting for anyone with a mind to look. Don't try to hide bank account logins, nuclear codes, or your Grandma's butt.
No one should see those things.
Except Grandpa.
I'm stuck! Can you help?
Of course! That's why we're called developers.
Reach out if you need some programming work on your project.