Showing posts with label Dashboard - Stats. Show all posts
Showing posts with label Dashboard - Stats. Show all posts

Wednesday, March 1, 2017

The New Followers Gadget - Blocking Followers

With the pre 2016 Followers gadget, the Followers population for a blog was managed through an Options link on the Followers gadget.

This required the blog owner to sign into the Followers gadget, to access the Options link. Authentication - and an owner specific Options menu - is no longer a pert of the Followers gadget.

It is possible to Block Followers, from a blog - the option is just not part of the Followers gadget, any more.

Previously, the option to Block a Follower was part of the Options menu, in the Followers gadget.

To ensure that only a blog administrator was able to Block a Follower - or do various other blog to viewer functions - the Block option was part of a complex wizard, accessed by a blog administrator.

This required the ability to authenticate a viewer - separately from the Blogger / Google login. This, in turn, made the Followers gadget complicated - and lead to occasional malfunctions.

To simplify the Followers gadget, there is no need to login to the gadget, any more.

Now, the ability to Block unwanted Followers is part of a blog administrator Stats page. On the Stats Overview page, look for the Followers count.

The number which displays the Followers count is now a link. Clicking on the number, one can access the "Manage followers" wizard.


This blog has 4,954 Followers. Click on "4,954" (right now).




And there is the "Manage followers for The Real Blogger Status" wizard. Each Follower now has a "Block" button, plainly visible.



Since only a blog administrator has access to the Stats dashboard page, there is no need for a separate Followers login. Just click on the Followers count, on the Overview page.

And the Followers gadget has only one option - the button, immediately visible to each blog viewer.
  • Follow (if not currently Following).
  • Unfollow (if currently Following).

The Follow / Unfollow button applies to administrators, authors, and readers alike. Now, there is no need to identify a person as related to a blog - except as whether this person is currently Following the blog.

Simplicity - for blog administrators, blog viewers, and Blogger developers.



When the #Blogger Followers gadget was re written in 2016, the "Options" menu - and the need to login to Following separately - was removed from the gadget.

The ability to Block selected Followers, previously part of the Options wizard, is now part of the Stats dashboard page.

Monday, February 29, 2016

Stats And "Don't track", And Custom Domains

Blog owners have been trying to block tracking their own Stats pageviews, for a few years.

This option has long been unusable, for blogs published to custom domains. Recently, Blogger Engineering updated the option - and the dashboard page with the link.

The new Stats option to "Manage tracking your own pageviews" is an improvement, over the old dashboard page.

The new Stats option page is run as part of the blog - not the Blogger dashboard - so it does not require third party cookie access. Unfortunately, this provides no obvious help, to people who publish their blogs to custom domains.

To see the problem, start from the Stats dashboard page.


Click on "Manage tracking your own pageviews".




And, you get "This site can’t be reached" or a similar error.



Custom domain published blogs do not support HTTPS access - even from the Blogger dashboard.


So, change "https:" to "http:", in the address window.



If you manually remove the "s", you can access the "Would you like to have your pageviews counted when you visit this blog?" wizard.

http://blogging.nitecruzr.net/b/statsCookieManage

You can't access the "Manage tracking your own pageviews" for a custom domain published blog, by simply clicking on the dashboard link.

This suggests an interesting detail. Now that "Manage tracking your own pageviews" runs under the blog URL, it will be subject to script filtering - for "blogspot.com", any applicable country local domains, and / or a custom domain URL.

You may need to correct your browser script filter, to make "Don't track" work, now.


Owners of custom domain published #Blogger blogs have been wanting to block Stats from counting their own pageviews, for a few years. This option is now available - but not in an obvious way.

Sunday, January 11, 2015

Stats Logs, And Cached Page Access

Some blog owners like to validate their Stats displays, using third party visitor logs like StatCounter.

Since Stats displays aggregated page view counts - not individual visitors - a blog owner will find many discrepancies between Stats and StatCounter. One observation might involve Stats indicating periods of no activity, where StatCounter shows an interesting visit.

A visit, registered by StatCounter - but not by Stats - indicates an apparent problem with Stats. Or, so the blog owner might think.

StatCounter displays page views, by counting clicks on the readers computer.


(Note): Please observe that "page views" come from both dynamic pages ("posts") and static pages ("pages") being accessed. When I refer to "page views", don't get confused about dynamic pages ("posts") vs static pages ("pages") - "page views" apply to both.

Stats displays page views, from the Blogger servers. If a page being accessed, by a reader, is already in cache on the readers computer, there will be no access to the Blogger server, and no Stats activity.

This discrepancy can contribute to confusion about visitor count. If two readers, sequentially sharing a public computer, access the same blog page, StatCounter may indicate two visitors.

If the first reader does not cautiously clear the computer before vacating, the second reader will access the page from cache - and will not register Blogger server activity. Stats will show no page views, indicating a second reader.

If a computer is being used with other people waiting for a turn, a reader may not have a chance to clear the computer before giving control to a second reader. The busier the computer, the greater the chance that Stats and StatCounter may show an apparent discrepancy.

There will always be differences between Stats and any other visitor log - just as there will always be differences between any two visitor logs, in general. A discrepancy is not always an inaccuracy.

Monday, November 10, 2014

Renaming Your Blog, And Historical Stats Pageview Counts

Occasionally, we see odd questions about Stats, and the history of someone's blog (or maybe, the URL of someone's blog), in Blogger Help Forum: Get Help with an Issue.
If I started my blog last year, why does my Stats display show pageviews from 2, or even 3, years ago?
and
If I rename my blog to a better URL, how do I carry the Stats numbers to the new URL?
Neither blog owner shows an accurate understanding of the historical nature of Stats pageview counts.

The Blogger servers record access activity by URL - not by blog.

Stats extracts pageview counts as needed, by URL, from the Blogger server logs. If the URL of your blog is "myfineblog.blogspot.com", and you request pageview counts for your blog, for "All time", you will see pageview counts against "myfineblog.blogspot.com", for Stats since May 2006 (as currently the case).

If the URL of your blog was "myexcellentblog.blogspot.com" until you renamed the blog to "myfineblog.blogspot.com" 6 months ago, you will see historical pageview counts for "myfineblog.blogspot.com" - which will include your blog, starting 6 months ago. You won't see pageview counts for "myexcellentblog.blogspot.com", from a year ago, because you'll be seeing historical pageview counts for "myfineblog.blogspot.com".

If someone else had a blog, published to "myfineblog.blogspot.com", before you renamed your blog to its current URL, your Stats displays could include pageview counts reflecting access to that blog. If "myfineblog.blogspot.com" was never used before you renamed your blog to that URL, it's possible that your pageview counts include attempted access to a non existent URL.

If you're using Google Webmaster Tools with your blog (and you should be doing that), you can check the access logs for "404 Not Found" events in the WMT logs. Just as a tree, falling in the forest, makes a sound even when nobody is around, so can access attempts exist against URLs where no blog is published.

Some referer spam appears to be sent to all likely URLs, ignoring whether or not a blog actually exists, at that URL. Referer spam is not unique to Blogger, and has been a problem since before Blogger became a major player in the Internet world.

If you just started a blog, or just renamed your blog to its current URL, your pageview counts can reflect historical referer spam, against your current URL, from before your blog was published to the current URL. As Blogger identifies specific referer spam campaigns, and eliminates some referer spam from Stats logs, this is one more possible cause of fluctuations in pageview counts.

If the possibility of seeing bogus pageview counts, for your blog as published to the current URL, does not please you, I will again point out that you'll get more out of your blog if you spend less time worrying about the details of the Stats displays, and more time working on your blog.

Look at activity before the blog was published as "noise", and look at current activity as "signal" - and work on improving the "signal to noise" ratio. Be aware of the value of your blog, and work on improving the value.

>> Top

Saturday, August 23, 2014

Reading Posts In Main Page View Affects Stats

Some blog owners don't understand why Stats displays show that no one is reading their latest post.
I know that my most recent post is being read - but Stats shows pageviews, for that post, as 0!
This owner does not understand the difference between main page, and post page, access.

If you read this blog, without being interested in any particular post, you can access the main page. On the main page, and other index pages, you'll see anywhere from 10 to 15 carefully summarised, recently published, individual posts.

Clicking on "Read more »", at the end of any of the summaries, you can read any complete article. This complete article, and others in this blog, is published as an individual post page - and summarised on index pages, using Jump Break.

Not every blog owner uses Jump Break, to display the posts. Some blog owners publish complete blog articles, in each index page post. Depending upon how any blog is designed, some readers may click on a link, to read any individual post - and others may read some posts from the main page.

Stats enumerates pageviews for individual post pages, in the "Pages" / "Posts" displays. Since the main page is an "index" page, main page activity is not tracked, in the "Pages" / "Posts" displays - and that causes some confusion.

For any given blog not using Jump Break in the posts, the unconscious decision to read a post from the main page, as opposed to a post page, is affected by various blog design details.
  • Physical size of main page.
  • Number of posts published on main page.
  • How frequently new posts are published.
  • Whether the blog is publicised, using main page links - or individual post page links.
  • Presence - and position - of the Archive index accessory, on the blog face.
  • Presence - and position - of any search accessories, on the blog face.
  • Use of label indexes - at the end of the posts, and / or a Label index on the blog face.
  • Use of links in post content.
  • Choice of comment display style - combined with the blog content which may or may not encourage comments.
All of these details, and more, may cause a reader to read a given blog article on the main page, or on an individual post page.

Physical main page size. Larger main pages require more scrolling. The more scrolling is involved, the greater the chance that the reader may find a link to an individual post page, click on the link, and read the article from the post page.

Number of posts published on the main page. Number of posts affects physical main page size. Thanks to auto pagination, some blogs may be displayed with a few posts on the main page, and other blogs with many posts on the main page. Blogs published with less posts on the main page will have more readers clicking on links to the individual post pages, for older posts that won't appear on the main page.

The most recent post published will appear at the top of the main page, in its entirety. Readers accessing the blog, using the Home (main page) address, are almost certain to read the most recent post as part of the main page. Other posts, further down the page, may or may not be read in the main page, or in individual post pages.

Frequency of publishing. Blogs with posts more frequently published will see older posts pushed from main page view sooner, increasing the chance that older articles will be read from the posts pages.

How the blog is publicised. Blogs that are publicised using the main page URL will see more traffic to the main page, while blogs that are publicised using the individual post page URLs will see more activity to the post pages.

Presence and position of the Archive index. If an archive index is present, and visible at the top of the page, a reader may click on an archive index entry, and read an article from an individual post page.

Presence and position of a search accessory. If a search accessory is present, and visible at the top of the page, a reader is more likely to use the search, and to read an article from an individual post page.

Use of a label index may lead to reading the blog using a label index page. Similar to main page, a label index page is a page which groups posts under the label in question. A label index page may be reached from an end of post label list entry, or from a Labels index accessory.

Pageview counts for label index pages, like main page, are not counted under "Pages" / "Posts", in Stats. Here, too, you can have articles read without clicking to the individual post pages.

Use of links in post content. Posts which contain direct links to other posts - as opposed to use of the end of post label index - lead directly to other individual post pages.

Comment display style, and use of comments in the blog. Blogs which use embedded comments will have activity on the individual post pages, when the reader feels the need to examine previously published comments, and / or publish a new comment. The embedded comment display, and entry form, are at the bottom of the individual post pages. The Comment Count Link - "nn Comments" - goes to the bottom of the individual post page, and will generate activity, as counted by Stats.

Blogs with full page or popup comments - and blogs which don't encourage comments - will have less activity on the individual post pages. The post pages are not loaded, with full page or popup comment forms. The full page and popup forms are published under "blogger.com", not under the blog's URL.

All of these seemingly insignificant details, which are present in every blog, in different combinations, will affect access to individual post pages, as opposed to various index pages (archives, labels, and main page).

This will determine whether access to a given article in the blog is counted (as a page or post) or ignored (as an archive, label, and / or main page). The infinitely variable combinations of these details will determine the relative "accuracy" of the Stats "Pages" / "Posts" display, for different blogs. You'll see similarly variable search engine indexing of the blog, with these combinations of details.

And remember also that in the "Page" / "Post" Stats lists, only the top 10 most active Pages and Posts are displayed, at any time. This will also affect "accuracy".

Sunday, April 15, 2012

Referer Spam Cannot Be Blocked, Immediately

That is the unfortunate truth.

Every day, some new member of Blogger Help Forum: Something Is Broken asks, innocently
What is all this traffic from dodgy websites?
and after we explain what the dodgy traffic is, and why it does not reflect real traffic, the next question is
So why doesn't Google block it? Why should I have it polluting my Stats displays, and be unable to find actual traffic in my counts?
and the unfortunate truth is simply that Google cannot block it, because it's not significantly different from normal traffic - and the insignificant difference is not easily detected.

Referer spam cannot be identified, because it is identical in structure to legitimate Stats pageviews - and because its content changes, constantly.

What does a normal blog page "pageview request" look like?

When you click on a link from, say, a post in Blogger Help Forum: Something Is Broken, to this article, your computer sends a single message to the Blogger server, containing three essential details.

  1. The IP address of your computer.
  2. The URL of a forum discussion, which contains a link to this article.
  3. The URL of this article.
From the message, the Blogger server creates a server activity record.
  1. An IP address.
  2. The URL of the page containing a link to the webpage requested.
  3. The URL of the webpage requested.

That server activity record, in the Stats display for the blog, is known as a "pageview".

Finally, the Blogger server starts sending web page content back to your computer, so your computer can display this article to you. As the webpage content is sent back to your computer, your computer receives, and displays, the received content - and asks for more content.

What does a referer spam "pageview request" look like?

Simple enough? So, what is referer spam? Simply, a single message from a spammer computer, to the Blogger computer, containing three essential details.

  1. An IP address - possibly, but not predictably, of their computer.
  2. The URL of the website being pimped (the spammed website).
  3. The URL of the blog being spammed (your blog).
From the message, the Blogger server creates a server activity record.
  1. An IP address.
  2. The URL of the page (supposedly) containing a link to the webpage requested.
  3. The URL of the webpage (supposedly) requested.

That server activity record, in the Stats display for the blog, is also known as a "pageview".

Finally, the Blogger server starts sending web page content back to the IP address provided. If the IP address does refer to the spammers computer, what is received is simply ignored. The spammer computer moves on, and sends another fake pageview message to another server - maybe referencing this blog.

The "pageview request" is generated, before referer spam discontinues.

The problem is simply that no web server can detect a message from a client computer, that results in a response that is just ignored. Web traffic is lossy, and clients drop offline constantly. Even if the response could be detected as ignored, the ignored request might still reflect legitimate activity, initiated by a client that immediately went offline.

There is simply no way for Google to block the spam - because the spam is simply one message that results in a response, by the Blogger server, that is subsequently ignored by the client computer.

That's it.

So why can't Google block the numbers generated by referer spam, as the referer spam hits the servers? Simply because the numbers may not really represent actual spam. They can, just as easily, reflect intense, legitimate activity - or possibly a devious attack against a legitimate website.

Google can only detect referer spam in context, against multiple blogs.

Specific pageview counts and details are observed in context - are blocked only after the same activity is observed against multiple blogs, over long periods of time (similar, in concept, to stateful network traffic analysis) - and the numbers are removed, retroactively.

All of this is a simple unavoidable side effect, of blog owners needing site activity figures that are not affected by script filtering by the blog readers, complicated by fraudulent activity by hackers and spammers.

Referer spam is not unique to Blogger - it is simply tuned to abuse Stats logs.

Please note that referer spam did not start with Blogger - it's an Internet wide problem. Even though it appears mindless and random, some of it is craftily designed and executed.

For a comprehensive look at how referer spam works, outside Blogger, see Wikipedia: Referer spam.

The problem here is threefold.

  1. Too many blog owners obsess over raw pageview counts.
  2. Too many blog owners do not understand the origins of referer spam.
  3. Too many blog owners are not interested in understanding the real problem.

That's it!

Monday, March 5, 2012

What Does Stats Provide, That Third Party Visitor Activity Meters Cannot Provide?

Not all blog owners realise how unique Blogger Stats is, in its design.

Some owners may idly suggest that Stats can easily be replaced by any third party visitor activity log / meter.
Why bother to use Stats? Since Blogger Stats shows referrer spam, it's pretty useless - just use SiteMeter, StatCounter - or Google Analytics.
They have no idea why Stats was designed as it is, nor what information Stats provides, that no competing product can possibly provide.

Every add-on accessory, such as any visitor activity counter / log / meter, has to be manually installed in your blog.

Most visitor activity counter / log / meter products require installation.

Simple accessories, which depend upon your visitor clicking on a link, can be installed easily - just add a clickable link on your blog - either in a post, or anywhere in the body of the blog. Visitor logs or meters such as SiteMeter or StatCounter, in order to produce usable statistics, can't depend upon the blog readers clicking on a link.

Most such accessories use add-on JavaScript code, installed in the body of the blog (as an accessory gadget), or in the blog template (installed using "Edit HTML"). With add-on code, that references any external server, the installed location on the blog page, of the accessory code, is crucial.

  • Install the add-on at the top of the web page (or in the template code), and as your reader loads each page, he / she gets to watch the page load pause, as it waits for a distant accessory server to respond (while recording the visit).
  • Install the add-on at the bottom of the page, and any reader, who closes the display before the page finishes loading, will not be counted by Analytics / SiteMeter / StatCounter.

In either case, the page takes longer to load. This causes reader impatience, and motivates the reader to close the display before the page finishes loading. The result - your blog gets one less new reader.

Most visitor activity counter / log / meter products are affected by filters.

Besides reader impatience causing statistical inaccuracy, all third party accessories that use JavaScript have a second problem - script filtering by our readers.

Analytics, SiteMeter, and StatCounter are known to be explicitly blocked, by some browser setting or third party application that may run on any given client computer. Some security products specifically list "sitemeter.com" or "statcounter.com" in their Block Lists.

A lot of malicious activity, encountered when surfing the web, can easily be blocked by proactive script filtering - just permit scripts, from any given domain, only when explicitly told to do so.

Every reader uses security accessories in the browser and on the computer - and many security accessories and settings provide script filtering. Most security is now provided as "deny by default, permit only on demand".

Most security products update automatically, as updates are produced - and this leads to other problems. Many of our readers, who are concerned with security, or who use computers that are well protected, may not be counted, consistently, by Analytics, SiteMeter, or StatCounter.

Stats does not require installation, and is not affected by filters.

Blogger Stats avoids the issues of page load delay induced impatience, and client filtering, by not using JavaScript add-on code. Since Stats is a Blogger accessory, it can retrieve data directly from the access logs produced by the Blogger servers. Access to server access logs:

  • Does not cause page load delays.
  • Is not subject to page load delay impatience.
  • Is not subject to reader security settings.
  • Does not require installation of any accessory, on individual blogs.

Besides the problems of our readers visits not being counted, we have the issue of what information is provided, and for what period of time. If you have installed SiteMeter or StatCounter on your blog, look at the displays provided. Each product will mention a limit of either 100 or 500 log entries - and will display details or statistics based upon the log used.

Many Blogger blogs get more than 500 visits in a single day - requiring blog owner visits to the log website at least daily, or to pay for extra service, to provide any benefit. And of course, that log was started only after the product was installed.

Blogger Stats, on the other hand, is able to provide statistics for the current day, week, month, and for "all time" (starting in May 2009, for all blogs in existence at that time).

Stats does not discard old statistics, they just extract from the server access logs, for any time range provided.

  • All time.
  • Last 30 days ("Month").
  • Last 7 days ("Week").
  • Last 24 hours ("Day").
  • Last 2 hours ("Now").

Any blog owner can see any available statistics, at any time. Stats never has to be installed, by any blog owners - it is already there.

Stats is vulnerable to bogus activity records, created by spammers.

Unfortunately, the biggest strength of Stats - use of the server access logs to gather the visitor activity data - leads to its best known weakness - abuse by referer spammers, which leads to inflated blog read counts.

It may help to understand that referer spam did not start with Stats - nor is referer spam unique to Stats. Referer spam has been around ever since people published websites, and displayed a visitor log extract ("My Recent Visitors") to make their website more interesting to new readers (The suggestion that "This website should be more interesting to YOU, because it has readers from all over the world!").

Stats, like every visitor activity counter / log / meter product, resets totals.

Besides the concern of referer spam, we see various evidences of confusion about Stats displays.


All of these limitations are simply the direct result of how Stats is designed.

Every visitor activity counter / log / meter product differs, from every other product.

In reality, both Blogger Stats and third party visitor activity logs or meters have their respective advantages - and neither choice can ever replace another.

  • If you want to see demographic details about some readers of your blog, you can use Analytics, SiteMeter, StatCounter - or any number of third party visitor activity logs and meters - after the chosen accessory has been installed.
  • If you want to see comprehensive statistics about all readers of your blog - without being limited by install time or reader security policy - only Blogger Stats will help you.

Fortunately, all products are free - and Stats requires no installation. Your Stats data is there, waiting for you - on the Blogger dashboard menu.

Saturday, February 25, 2012

Search Engines, Visitor Logs, And Country Domains

Some blog owners are seeing the recently added Country Code Top Level Domain Aliases in their visitor logs / meters, and various non Google search engines.

Possibly unaware of the aliases, they are afraid that their blog has been hacked.
My SiteMeter logs show that I've had incoming traffic from "mybloggerblog.blogspot.in". Clicking on one of the links in SiteMeter, I see my blog, "mybloggerblog.blogspot.com". Has somebody cloned my blog?
In reality, the scenario is not so ominous.

Those of us aware of the CC aliases, and how they are being used by Blogger, will understand that simply seeing a non canonical alias in our referer lists, in any search engine or visitor log / meter, is not an indication of malicious activity.

People unfamiliar with the country code aliases may be confused.

People long used to seeing only "blogspot.com" and "google.com", and not yet experienced with the CC aliases, may become confused, however. Blogger blogs owners with long established blogs that have audiences outside the USA are probably used to seeing all references to their blogs based on the canonical URL, such as "mybloggerblog.blogspot.com".

Now that BlogSpot published blogs are being served using the CC aliases, in many countries outside the USA, the readers of BlogSpot published blogs are seeing each blog under non "blogspot.com" URLs in some search engines, and in many visitor logs and meters.

Many search engines will aggregate search references, to the canonical URL.

Most major search engines, which reference the "canonical" tag in the blog header, are aggregating all SERP entries to use the "blogspot.com" URLs. Our important search reputation is not being fragmented, such that readers in Australia provide reputation to "blogspot.com.au", readers in India provide reputation to "blogspot.in", readers in New Zealand provide reputation to "blogspot.co.nz", and so on.

Every hit, from every reader in every country, still provides reputation to the canonical alias, "blogspot.com".

Some specialised search engines like Alexa, DMOZ, etc - and most visitor logs like SiteMeter, StatCounter, and Stats, may not be designed to reference the canonical tag. It's also possible that visitor logs, by their nature, should not aggregate CC aliases to the canonical URL - as the country code, relevant to the individual readers, may be important to some blog owners.

Until the canonical tag is used by every Internet service, there will be confusion.

Until the use of the canonical tag, and the CC aliases to our readers, becomes mature, it's possible that we will see various oddities like a perceived problem with Alexa, SiteMeter, or StatCounter. It's likely that not all Internet services will ever reference the canonical tag consistently, and aggregate all statistics and visitor demographics, canonically.

Given the latter probability, this may be yet one more reason why Blogger Help Forum: Something Is Broken may never go out of business.



Some Confusion Over Use Of The CC TLD Aliases, By Search Engines And Visitor Logs
http://blogging.nitecruzr.net/2012/02/some-confusion-over-use-of-cc-tld.html

Search Engines And Visitor Logs, And The Country Specific Domains
Search Engines, Visitor Logs, And Country Domains
http://blogging.nitecruzr.net/2012/02/search-engines-visitor-logs-and-country.html

Monday, December 19, 2011

The Stats "All Time" Display, And The 2010 Numbers

Occasionally in Blogger Help Forum: Something Is Broken, we see a curious question.
My blog Stats display is missing a complete year.
The problem is actually right there, in front of all of us - if we look.

Look at the Stats Overview tab, and the graph at the top of the display.

What happened to "2010"?


My suspicion is that it's a deliberate omission, to get the graph to fit in the limited horizontal space. How will they get "All Time" to fit in that space, as the Stats display gets older, and "All Time" covers more years?

That being the case, it should not be that much work to add a little "broken line" symbol in the border, between "2009 October" and "2011 March". Look how smoothly the line flows, in my graph, right through 2010. What does your blog show?

Fast forward to 2015, and we'll know the answer.

And in 2012, we now see the same display oddity with the numbers from 2011.

>> Top

Monday, November 7, 2011

Referer Spam Does Not Represent Real Traffic, To Our Blogs

We've been discussing referer spam for many years.

Every week, besides many people who wonder
Why doesn't Google put an end to this, for good?
there are occasionally some folks who wonder
But is this all bad? Doesn't this help us in our overall Blogger statistics as far as traffic counts go? If so, it's not all bad - for those of us with less than ginormous followings.
And both attitudes reflect people who just don't understand what it is.

We've already discussed, repeatedly, why Google can't just put a end to it, unilaterally.

The latter musing, considering that it may possibly be beneficial to any Blogger blogs, is no more valid than the former. Referer spam simply cannot be blocked, because it is not different from legitimate traffic.

Stats logs entries, from referer spam, do not reflect people viewing the blog.

The numbers reflected in our Stats logs do not represent any actual traffic against our blogs, or any websites with links to our blogs. The only person who benefits from referer spam is the owner of the advertised (fake referer URL) sites - and that happens only when we click on the links in the Stats display.

Only Stats, which builds its pageview counts and graphs using the Blogger server activity logs, is subject to referer spam. All third party visitor logs and meters, which depend upon snippets or widgets added to the blog template, are not subject to this problem.

Don't click on the links - and use a third party visitor log for verification.

So, besides my facetious advice that you simply
Don't click on the links.
comes equally facetious advice that you
Get a third party visitor log / meter, for accurate and comprehensive pageview counts.

Jump Break, Main Page Contents, And Search Engines

The articles in this blog, which discusses production and use of Blogger blogs, are written as posts.

The various posts are combined, using embedded links, in different ways. Each new post appears on the main page, as it is written - and the various posts, appearing together on the main page, create opportunities for confusion, with the readers of the blog.

Long ago, the task of moderating comments was rather depressing to me, as the focus of many of the comments made me think that nobody was actually reading the articles. Maybe, I would write an interesting post about URL availability; but when moderating comments, I would find questions about posting comments on static pages. Or maybe a post about dynamic template concepts would attract complaints about referer spam.

Why should I publish my advice, if nobody cares enough to read the articles and comment relevantly?

Just previous to this post, I wrote about Stats displays, and the contents of the Posts lists.

In the process of writing the latter article, I discovered one obscure benefit of using "Jump Break" - and how "Jump Break" affects main page view, search engine indexing, and finally, relevance of comments to post subject.

A home page, with a variety of posts, naturally produces un focused comments.

Why the apparent lack of focus, of the comments? One reason is that many different posts, published one after the other, appear in sequence, in the blogs main page.

People will read the posts - and the search engines will index the posts - using main page view. Only after newer posts force the older posts, one by one, from main page view, will the individual posts have any significance - to people or search engines.

Using my example above, and looking at my main page when this post was new, one would have found a post about URL availability, published a week after a post about posting comments on static pages. By the time the search engines indexed the latter post, I would have published the former post. The post about URL availability would be visible in main page view, ahead of the post about posting comments on static pages.

Clicking on the link to my blog, attached to a SERP entry referencing static pages, the reader will read my main page from the top, find the previously visible post about URL availability, and the Comments link following the post. Clicking on the first Comments link found, the reader will post his question about static pages, against my post about URL availability.

Use of Jump Break gives a home page that can be easily read, top to bottom.

So, what effect does the use of "Jump Break" have on this problem? Using "Jump Break" on all main page posts makes it more likely that a potential reader of the blog, following a home page link to the blog, has more chance to see all recent posts, with their summaries.

The reader is more likely to scan down the page, see a summarised relevant post, click on "Read more" - and read the relevant post, on the individual post page, before commenting.

Use of Jump Break gives more weight to the individual posts, as indexed.

Additionally, with the posts summarised in main page view, the search engines will find less content on the main page. The full posts will be indexed as individual post pages, more than as part of the main page. This gives more weight to the individual posts, and less weight to the main page.

When indexed using an automatically generated, robust sitemap (2014), the posts will appear individually in SERP lists, decreasing reader main page confusion. Each SERP entry, pointing to an individual post, will be more relevantly focused - giving it more weight than a SERP entry, pointing to main page view.

Use of Jump Break, consistently, produces a win-win-win scenario.

In summary, careful and consistent use of "Jump Break" leads to:

  • Better focus on individual and relevant blog articles, by the search engines.
  • Less confusion to the blogs readers, when accessing the blog using SERP hit lists.
  • Less frustration for the blog owner, when moderating comments.

It's really a win-win-win, when used consistently. And, it's so simple to apply, on a post by post basis. Check it out, in action.

Monday, October 31, 2011

Stats Not Displaying Newer Posts, In "Posts" Lists

The problem of last week, with Stats, was fixed late yesterday, and our Stats displays once again are showing Posts pageview counts and enumerating individual Posts. Now, we have a perceived problem, being reported by newer blog owners.
My Stats display does not show my newer posts!
This concern is visually valid - but it's not real. It's most common with blogs that have just over 10 posts, which are owned by people who are not aware of the Stats display limitations, as we have explored.

The Stats Posts displays enumerate the 10 most popular posts, for any given time period. Newer posts will seldom appear in the Posts lists, for many blogs.
  • The "Posts" lists enumerate individual posts, and shows pageview counts for posts viewed in single post view. Newer posts will be displayed in their entirety on the main page, and read as main page views.
  • The lists show only the 10 most popular posts. Newer posts, not yet indexed by the search engines, or linked by your readers, won't have as many inlinks - and the post page URLs won't get as much traffic from other blogs and websites.
Owners of newer blogs will not be aware of these details - and with just over 10 posts, may not see the significance, in their Stats displays. These owners will simply see, from time to time, posts that don't appear in the lists.

If you look at the main page, for this blog, you'll see use of "Jump Break" in my newer posts. Each of these posts, to be read in their entirety, can only be read using the "Read more" link - and from the individual post page. Look at the address window above.
http://blogging.nitecruzr.net/2011/10/stats-not-displaying-newer-posts-in.html
Since you're viewing these words, this post is being counted in Posts, as a pageview. Thus the Posts lists, for this blog, will enumerate this post, sooner.

Here, we see another benefit of using "Jump Break" over other auto summarisation techniques. The "Jump Break" links directly to the single post view of each post - and it uses HTML, which makes it search engine friendly. Some previous auto summarisation techniques used JavaScript to hide the full post content, preventing search engines from indexing the full post text.

Besides encouraging the post content to be read as a post page, the search engines will index post content in the post pages. The archive retrievals, and main page, will only list the partial content of each post - and search engine hit lists will contain more relevant content.

>> Top

Sunday, October 30, 2011

Stats Not Displaying Individual Posts, In Detail Lists

For several days now, we've seen various reports from anxious Blogger blog owners, in Blogger Help Forum: Something Is Broken, lamenting the lack of detail information in their Stats logs.
My Stats logs does not show the page views for particular posts.
This is just one example, of the many ways that blog owners perceive, and report, the ongoing problem.

If you look at the Stats Overview or Posts display, for any blog with any popularity, in the "Now" or "Day" time range, you'll likely see the well known advice
No stats yet, check back later.
When initially reported, this was only visible in the "Now" time range. Now, the effect is seen in "Day", and for some, less consistently trafficked blogs, in "Week" also. The effect is visible, consistently, in both the Classic GUI (brown / dark blue display), and the New GUI (2011) (brown / orange on white display).

This problem is apparent, for most blogs, in the "Posts" tab.
Most blogs with consistent traffic will show this affecting only the detail Posts lists. The "Now" and "Day" Posts lists, as noted, show "No stats yet, check back later.". The "Week", Month", and "All time" Posts displays show the Posts lists from before the problem first occurred. Both the Posts names in the lists, and the pageview counts for each post listed, are frozen.

This blog shows no effect in pageview counts, outside the Posts detail lists. I've carefully examined the graphs for "Now", "Day", "Week", "Month", and "All time", in both the Classic and New GUI, for this blog - and I don't see any count discrepancies. Your observations may agree or disagree - and I await your comments.

We have a Rollup discussion, in Blogger Help Forum.
We have an ongoing rollup discussion, in Blogger Help, where the scope of the problem is being discussed. My original perception of the problem began as we explored the latest wave of referer spam; I am today trying to determine if the two events are related.

An earlier outage may be related to this problem.
We also had an interesting 2 hour outage, a week ago, where no Stats data (counts, or details) was available for the previous week - and some blog owners are wondering if that issue is related. We have no references for the latter episode, as we escalated that problem in real time, and Blogger Support was able to fix it, immediately.

That problem was complete (as noted, both counts and details were available), it was immediate (it showed on all Stats displays for the previous week, retroactively), and it was total (the immediate nature and effect on the forums made it an obvious BloggerFire). This problem, according to my observations, is neither.


(Update 18:00): Blogger Support has fixed this problem.

Friday, October 28, 2011

Nitecruzr.Net Hits The Big Time

This morning, we're seeing a number of questions in Blogger Help Forum: Something Is Broken.
Why are my Stats displays showing
No stats yet, check back later.
yet again?
and more interestingly
"blogging.nitecruzr.net" is showing multiple hits in my Stats log!
And none of this is really surprising, personally.

The bad guys, who have been serving various waves of referer spam against the many Blogger blogs, have recently included "nitecruzr.net" in their lists of websites, falsely advertised by their attacks.

I've been using this blog to talk about spam, in general - and about referer spam, in particular - for years. This week, the people who operate the referer spam networks are targeting me, in a Joe Job attack, using Stats logs to confuse Blogger blog owners.

In crime novels, it's called a "frame up". In networking, what they are doing is vaguely similar to a "smurf attack", using the various Blogger blog owners, in an attempt to overwhelm the forums.

I guess I should be flattered. Let's try to keep it in perspective, though - and keep working on your blog.

Friday, October 14, 2011

Dynamic Templates And Visitor Information

As the dynamic templates continue to be installed on various Blogger blogs, more and more blog owners are noticing problems with their visitor logs.
I installed a dynamic template on my blog, and my Stats display shows
No stats yet, check back later.
and
StatCounter shows no traffic, now that my blog uses the dynamic views.
These reports come from people who don't realise how the new templates work - and why they don't seem to work, in these cases.

Blogs that use the dynamic views are able to display content faster.

The display speed improvement is possible, because dynamic templates use the blog feed - which is downloaded from the Blogger newsfeed servers, and rendered as a web display on our computers. Non Dynamic templates display static or semi static HTML (with CSS, XML, and other extensions) - rendered into web displays on the Blogger servers, and downloaded as web content.

The differences in web page display are not consistent with how visitor activity is observed.

  • Dynamic templates provide less customisation ability, for most blog owners.
  • Newsfeed content is simpler than web pages.
  • Newsfeed content is read one display page at a time.
  • Displayed dynamic pages contain less formatting tweaks.
  • Individual posts, when displayed, are already cached on the local computer.

Dynamic templates provide less customisation ability, for most blog owners.

The downloaded dynamic templates are very simple, and contain no custom code for different blogs. Once downloaded for your blog, they will work the same for my blogs, and for my neighbours blog - with all blogs using dynamic views. This makes these blogs very stable.

Newsfeed content is simpler than web pages.

Non rendered newsfeed content is much simpler than rendered display pages. Once the template code is downloaded once, downloading the data is even quicker than downloading the templates.

Newsfeed content is read one display page at a time.

The newsfeed content is read from the Blogger newsfeed servers one display page at a time, and cached on each readers computer. As each blog is read, the most recent articles are at the top. Many readers, as with viewers, will never go beyond the first display page.

Displayed dynamic pages contain less formatting tweaks.

The displayed pages contain very little accessories and formatting, which is so popular with many blog owners, and which generates load on networks and processors.

Individual posts, when displayed, are already cached on the local computer.

When an individual post is displayed, the cached content is already right there, on the computer.

There are disadvantages to having all content cached, however.

The advantages, and the disadvantages, of the dynamic views originate from the same basic details - use of the blog newsfeed, and of a very simple and standard template. People who distribute their blog as newsfeed subscriptions have been asking the same question, for years.

How do I track my subscribers, as well as I track my viewers?

There is no easy answer to this need. With all content cached on the local computer, tracking reader activity is not so simple.

Tracking reader activity is a challenge - for both Blogger and non Blogger features.

Both third party visitor logs and meters, and the Blogger Stats feature, have problems providing details about our readers - with our blogs using the dynamic templates.

  1. Older installations of third party products use HTML / JavaScript, installed directly into the blog templates (generally Classic, but some Layout and Designer templates). The dynamic templates will not include this third party code. Newsfeeds contain only very simple text, and pictures, with no scripts.
  2. Newer installations of third party products use HTML / JavaScript / XML gadgets, installed as accessories into the header, footer, or sidebar sections of the display. The dynamic templates, right now, contain neither sidebars nor accessories.
  3. Stats reads the Blogger server activity logs, generated as rendered display pages are downloaded to the client computers. Newsfeed content may not require the same server activity, and generate comparable activity logs.

None of these features will be easily included in the dynamic views, without some rethinking of the simple and standard dynamic template structure.

  1. Blogger has suggested that they will provide support for JavaScript code, in the dynamic templates. We can install third party JavaScript code directly into the dynamic templates, making them more complex, and unique for different blogs.
  2. Blogger has suggested that they will provide sidebars, and support for accessory gadgets. We can install third party JavaScript code as sidebar gadgets.
  3. Similar to accessory gadgets used for third party JavaScript, or to JavaScript embedded into the templates, Blogger can provide additional code to drive Stats displays, and provide pageview counts, into the template code.

Unfortunately, all of these alternatives will come with a price. We will see increased code complexity, increased downloaded code volume, and increased network and processor activity on our computers.

In short, do not expect to see detailed visitor information, comparable to what we see right now in Stats or third party products, immediately - and watch for increased latency once these features are added.



Owners of #Blogger blogs occasionally observe discrepancies in visitor activity, when they change their blogs to use dynamic templates, and examine their visitor logs.

Some - but not all - changes come from reader reaction to the dynamic template displays and features. Other changes involve how the dynamic templates are processed, by the local computers being used by the blog readers.

Monday, October 10, 2011

Use A Proxy Server, When Following Stats Links

We've been observing the ongoing problem with referer spam since the beginning of the year - yet we see that some blog owners still haven't heard of the problem. Some folks who are advised later, to be more cautious
Don't click on the links!
come back with anxious queries
I already clicked on the link! What will happen now? Have I been hacked?
Here, there's no authoritative answer.

When you click on a Stats traffic source link, and get an eyeful of porn or spam, you're not going to be happy - but hopefully, if your computer is well protected, chances are probably good that you're OK. On the other hand, if this makes you anxious, it would not be a bad idea to get the computer checked out.

In the future, if you must check out your Stats traffic sources, use a proxy server. Again, don't click on the links - copy the URLs, and paste them into the proxy server address window.

If you surf to a referring website and like what you see, then go back, click on the link, and bookmark the URL. Just do this after you screen the traffic source.

If, one day, Blogger uses SafeSearch to screen the URLs, we'll be safe again. And shortly afterwards, referer spam will dry up as the people who pay for spam based advertising stop paying.

>> Top

Wednesday, April 14, 2010

Private Blogs And Your Visitor Log

There are known limitations, to the effectiveness of making a blog private.

The problem of access latency, where a blog made private won't block everybody immediately, is one. Another is the possibility of co workers of a legitimately designated reader being able to read a private blog, on an office network that uses a caching proxy server. But there are other perceived problems with private blogs, that don't actually exist.

One perceived problem is seen when examining the visitor log for a private blog. Some one without access permission, loading a private blog, will load the "Private Blog" interstitial warning on top of the requested page. The visitor log will show the page in question being loaded. But look closer - do you see any other pages being loaded?

A log from StatCounter is perfect for this task. For any visitor to your blog, you can see a record of each link clicked during the visit. For an uninvited visitor to a private blog, you'll likely see one click - the "Entry Page" - and that's it. And even if the "Entry Page" is listed in the visitor log, chances are that all that was actually seen was the interstitial page.

So if you're examining the visitor log for your private blog, relax. Your private content is, most likely, safe.

Navigate» Become author for this Blog