Blogger's Don't track my views setting gets reset after some time - Probable cause; Exploring Chrome extn for notification if reset

Given below are edited extracts from my recent chat with ChatGPT (CG), "Blogger own views tracking issue".

Me: About Blogger Stats: Manage tracking your own pageviews:

I am having a problem of some of my Blogger blogs reverting to OFF for "Don't track my views for this blog." even though I do not make such a selection on any of my devices where I am logged in with the same Google a/c and access my Blogger blogs. On my computer devices, I have gone to Blogger in each device and set "Don't track my views for this blog." to ON. However, the problem is still happening at times.

My suspicion now is that on my mobile device, I sometimes access my Blogger blog through Chrome. Perhaps access from that mobile browser is triggering the problem. R u with me so far?

...

Me: How do I check whether my mobile (Android) Chrome browser has this setting to ON or OFF for my Blogger blogs? Should I try to access Blogger.com on mobile Chrome and then check? ... Note that I have Blogger app installed on my mobile but I don't recall seeing such a setting there.

CG: This setting doesn’t live in the Blogger mobile app at all — you’re right that you won’t find it there. It’s tied to your Blogger account settings per blog, and Blogger enforces it via a cookie in your browser (not a global Google-account flag). ...

[CG suggested logging in to Blogger on Android Chrome.]

Me: Hmm. Signing in on blogger.com on mobile Chrome with its small screen size would be problematic. Isn't there some easier way?

CG: You’re right — Blogger’s full dashboard on a mobile screen is cramped and fiddly. Unfortunately, Blogger hasn’t exposed the “Don’t track my views” toggle in the mobile app or in a lightweight mobile UI.

...

Me: Can u search the net and see if others are facing a similar problem with Blogger and if so, how they are handling it?

...

Me: In my case, it retains the value for some days across browser open/close as well as system restarts. Then it gets automaticatically set back to OFF. Pls. give me articles that match that.

CG: Yes — I found a relevant thread from Google Support that more or less matches your description: people saying their “Don’t track my views” setting in Blogger does stick for a while (across browser restarts etc.), then later reverts to OFF automatically. Google Help

Here are the key parts I found + what people deduced, which seem similar to what you’re seeing:

🌐 What others said

From the Google Support thread “My selection of 'Don't track my views for this blog' keeps resetting”:

A user writes that the option resets even though they didn’t explicitly change it. Google Help
Someone else (or the official reply) points out that the cookie associated with that setting is a session cookie — meaning it may have no long-term expiry and thus can expire (or be lost) when certain events happen (e.g. logging out, session ending, or possibly after some time). Google Help
Also people in that thread say it reverts after some days. Google Help

So this matches your pattern: keeps ON for some days (so the session/cookie is working), then flips back (when session/cookie is no longer valid, or gets cleared).

...

Me: https://support.google.com/blogger/thread/352039900?utm_source=chatgpt.com seems to match my case. I looked up Dev Tools in Chrome and found that I too have an _ns cookie which is set to session. Now as per above article: Session" => "expire at end of the session", so it will be deleted when you log out or when you close the browser (and do not restore the previous session).
------
I usually don't log out of Google but sometimes that happens [Google forces a re-login OR I do log out temporarily for some reason]. So does it mean that every time I log out of Google, the cookie gets cleared? Note that the setting is remebered across system reboots (but without me having logged off from Google).

CG: Yes — you’ve pieced it together exactly right. Let me unpack it clearly:

🔑 About the `_ns` cookie

That _ns cookie you saw in DevTools is indeed the one Blogger uses for the “Don’t track my views” flag.
It’s marked as a session cookie, which means:
- It has no explicit expiry date.
- Its lifetime is tied to your login session in that browser profile.

✅ Why it survives some reboots

If you don’t log out of Google and you restore the browser session (Chrome remembers your tabs and cookies), then the _ns cookie stays alive.
That’s why your setting persists across browser restarts and even system reboots — as long as you remain signed in and Chrome keeps your session intact.

❌ Why it resets

If you log out of Google in that browser, the session is considered ended → Chrome deletes session cookies tied to that login → _ns cookie vanishes.
Next time you log in, Blogger won’t see the _ns cookie, so it defaults back to OFF.
That’s exactly the “after some days, it reverts” behavior you’re observing.

⚠️ Implication

Yes — every time you log out of Google on that browser profile, you should expect the “Don’t track my views” setting to reset, because its cookie is wiped along with the logout.

👉 Two ways people handle this, based on what I’ve read:

Avoid logging out of Google on the browsers/devices where you need this setting stable.
If you must log out sometimes → just get into the habit of re-checking Stats → Settings after logging back in, and re-enable “Don’t track my views.”

Me: Hmm. Sometimes I choose not to restore Google Chrome session in cases where it prompts me. Does that mean that it would get reset then?

Also at times, I close all Chrome tabs having Google account related sites. Will that also result in the cookie getting reset?

CG: Good questions 👌 — let’s separate the two scenarios:

1️⃣ When you don’t restore the Chrome session

If Chrome is closed, session cookies (like _ns) normally die unless Chrome restores them.
That’s why restoring the session usually preserves the cookie — Chrome treats it as “continuing the same login session.”
If you choose not to restore, Chrome starts a fresh session → session cookies are gone → _ns cookie disappears → Blogger resets to OFF.

So yes: if you skip restoring, that can cause the reset.

2️⃣ When you close only Google-related tabs but leave Chrome open

Simply closing Gmail/Drive/Blogger tabs doesn’t kill the _ns cookie.
As long as Chrome itself is still running and you’re still signed into Google in that browser profile, the cookie stays alive.
The reset only happens when:
- You log out of your Google account in Chrome, or
- You close Chrome entirely without restoring the session later.

✅ So in practice:

Logout or non-restored browser exit → cookie wiped → setting OFF.
Closing just Google tabs (while Chrome is still open) → cookie stays.

Me: what if I close Chrome browser and do a PC reboot? Note that in such cases Chrome remembers my Google account login. But will it delete the session cookie?

CG: That’s a subtle but very important case 👍 Let’s unpack it carefully:

🔑 What happens when you close Chrome + reboot PC

Chrome shut down:
- When you close Chrome, all session cookies are supposed to be discarded.
- BUT Chrome has an exception: if you have “Continue where you left off” enabled or you manually restore the previous session, Chrome reloads those session cookies.
- That’s why your _ns cookie sometimes survives across reboots.
PC reboot:
- A reboot itself doesn’t matter — the key is what Chrome does on restart.
- If Chrome remembers your session (tabs + cookies), then _ns comes back and Blogger still sees “Don’t track my views = ON.”
- If Chrome starts fresh (new session), then _ns is gone, Blogger resets to OFF.
Google account login persistence:
- Chrome remembering you’re signed into Google is a separate thing from Blogger’s _ns cookie.
- Even if your Google login persists (so Gmail/Drive open without password), the _ns session cookie may still have been discarded — meaning Blogger thinks the tracking preference was never set.

✅ So in short:

Close + reboot + restore session → cookie survives → setting stays ON.
Close + reboot without restoring → cookie is gone → setting resets to OFF.
The Google login persistence doesn’t guarantee Blogger’s “Don’t track” preference survives, because they’re controlled by different cookies.

👉 Do you want me to show you how to check Chrome’s startup setting (“Continue where you left off”) and make sure it’s always restoring sessions, so you reduce the chance of Blogger resetting things?

[I said yes to above ... Settings -> On Startup showed that 'Continue where you left off' is selected.]

Me ... But even with that, in some scenarios (like me having to relogin in Google or me choosing not to restore session when presented with that choice - usually on system hang followed by system forced reset/reboot), I may have been not continuing the previous session, and that's where I may have lost the cookie setting. Am I right?

CG: Yes 👍 you’ve got it exactly right.

Even though “Continue where you left off” is selected:

✅ If Chrome closes/reopens normally → _ns cookie stays → Blogger remembers Don’t track my views.
❌ If you choose not to restore session (like after a crash/system hang reboot) → Chrome discards the old session cookies → _ns cookie is lost → Blogger resets to OFF.
❌ If you re-login to Google (sign out or session expires) → session cookies are cleared → Blogger resets to OFF.

So the behavior you’re seeing — Blogger remembering the setting for days, but then “mysteriously” resetting — is consistent with these scenarios.

👉 In short:
Your suspicion is correct — it’s not random; it happens only when the session continuity is broken (manual no-restore, forced reboot without session restore, or re-login).

Me: How can we confirm that _ns indeed is the related Blogger cookie?

CG: Good question 👌 — confirming that _ns is the cookie tied to “Don’t track my views” needs a bit of detective work, but it’s possible. Here’s how you can check:

🔎 Method 1: Manual testing with DevTools

Open Chrome → Go to Blogger Dashboard.
Open DevTools (F12) → Application tab → Storage → Cookies.
- Look for the _ns cookie under blogger.com.
- Note its value (e.g. 1 or 0) while your setting is ON.
Now go to Stats → Manage tracking your own pageviews and toggle the setting to OFF.
Refresh and check the cookie value again.

If _ns changes (or disappears), that’s strong evidence it’s the one controlling the setting.

...

Me: Method 1: The value is 2 now with Don't track setting selected. Shall I uncheck it and see if the value changes?

[CG said yes.]

Me: On unselecting it, and refreshing cookies info. in Dev Tools, _ns cookie is not shown (so cookie must be getting deleted). On selecting it, and refreshing cookies info. in Dev Tools, _ns cookie is shown with value as 2 (cookie must be getting created).

CG: Excellent 👏 — that confirms it beyond doubt:

✅ When “Don’t track my views” is ON → Blogger creates _ns cookie with value 2.
❌ When it’s OFF → Blogger deletes _ns cookie.

So _ns is exactly the cookie that stores your “don’t track my pageviews” preference.

🔍 What the behavior means

_ns is a session cookie → it’s not persistent.
That’s why it survives across browser reopen/reboot only if the session is restored.
If session continuity is broken (logout, crash, or you choose not to restore), _ns vanishes → Blogger defaults to tracking your views (OFF).

👉 Now you’ve got proof.

Would you like me to suggest ways to make _ns behave more “persistent” (so you don’t lose the setting as often), like using Chrome cookie overrides or extensions?

Me: https://support.google.com/blogger/thread/352039900?utm_source=chatgpt.com suggests changing session to 2050 using Dev Tools.

...

Me: I am hesitant to do the DevTools fix as it is a hack and not a Google suggested fix. Don't know if that might trip something else up. Instead is there some easy way that I can get notified when I visit Blogger that the setting is OFF?

[CG gave some options including a Chrome extension option.]

Me: My own Chrome extension (with you providing source code) is something I am willing to try so long as that does not create a significant performance issue. The extension can fire only when Chrome process is started (not on new tab).

[CG provided some code. I went through many iterations but did not get a proper solution. There were two problems with CG solutions:

Retrieving and testing the cookie was not working properly.
The message from the Chrome extension would go to background worker log whereas I wanted an alert.

Eventually I decided to stop doing the vibe-coding effort. Later I felt I should invest a little time in learning about Chrome extension development and see if I can figure out the cause of the above issues in CG provided Chrome extension code. For learning, CG gave some simple extension code but that too tripped up on showing the message part. So I then switched to going through Chrome extension documentation.]

Me: I am going to try this documentation tutorial extn https://developer.chrome.com/docs/extensions/get-started/tutorial/hello-world

...

Me: it worked as expected. but it shows a static popup. ...Next step would be to see how it shows a dynamic message generated by the extn. .... I will try that later .... eventually I hope to get back to the code you gave and then examine for myself why your code is not working.

============================

Search This Blog

Ravi S. Iyer: Software Development