Jetpack site state not work proerly on sub-domain

can jetpack update (3.1.1) will resolve the issue?? At-least can We make any changes in php or js file to hide #x(loading title) message in jetpack site stats. If yes just provide me file name. I will try hide it.

can jetpack update (3.1.1) will resolve the issue?? At-least can We make any changes in php or js file to hide #x(loading title) message in jetpack site stats. If yes just provide me file name. I will try hide it.
In network admin under jetpack -> Sites, two sites listed:
1)stratavant.roi-selling.com
2)blog.roi-selling.com
In the above 1 is deleted Now if any one visit stratavant.roi-selling.com site it will redirect to this roi-selling.com. I hope this will help us to resolve issue. When we visit this link https://stratavant.roi-selling.com/about-stratavant/ count of #x(loading title) is increases. So now my question is when view count increase means 1) when we click on link like https://stratavant.roi-selling.com/about-stratavant/ as example
or 2) when stravant.roi-selling.com changes to roi-selling.com (when domain redirect). Is their any setting to manage this thing or we need to change those link manually..

On your local instance, if you have simply copied the database from production to staging, your local site believes it is connected correctly (as the production site), so it would load the tracking pixel.

If visiting a post #2 that doesn’t exist in production, it would register to us as a view, so that’s what is being displayed.

If you visit https://192.168.200.14/stratavantDev/blogs/?p=2 and a page appears, this is likely what is happening.

As far as editing a file, it is not possible. The data is being stored on our servers and fed to your site via a remote request.

On your local site, I would encourage you to activate Development Mode ( https://jetpack.me/support/development-mode/ ) which would prevent the tracking pixel from loading and prevent future development views from registering.

Do you know what those posts are? Typically, you can use the ID to see the post (e.g. https://blog.roi-selling.com/?p=2 , but that is returning the home page.

You can attempt to load the post in your editor via by visiting your site’s admin area (e.g. https://blog.roi-selling.com/wp-admin/ ) and changing the URL to https://blog.roi-selling.com/wp-admin/post.php?post=2&action=edit for #2 or https://blog.roi-selling.com/wp-admin/post.php?post=78&action=edit

I suspect it may be a custom post type that isn’t set to sync data with WordPress.com, so we don’t have access to the post title to display it.

I check both site again so I found something #2(loading title) are pages exists on https://roi-selling.com means on main site. As per your suggestion I open in admin area https://roi-selling.com/wp-admin/post.php?post=2&action=edit . This pages are exists on https://roi-selling.com not on https://blog.roi-selling.com/ . But problem is having on blog why??. It is because of .httaccess ?? Here is code of htaccess

rewriteengine on
rewritecond %{HTTP_HOST} ^stratavant.roi-selling.com$
rewriterule ^(.*)$ “http\:\/\/roi-selling\.com\/$1” [R=301,L] #5399bb7d8a256

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteBase /
# add a trailing slash to /wp-admin
</IfModule>
# END WordPress
# BEGIN wtwp_cache
# END wtwp_cache
# BEGIN wtwp_security
# END wtwp_security
rewriterule ^index\.php$ – [L]
rewriterule ^wp-admin$ wp-admin/ [R=301,L]
rewritecond %{REQUEST_FILENAME} -f [OR]
rewritecond %{REQUEST_FILENAME} -d
rewriterule ^ – [L]
rewriterule ^(wp-(content|admin|includes).*) $1 [L]
rewriterule ^(.*\.php)$ $1 [L]
rewriterule . index.php [L]
————————————————–
can I make changes like rewritecond %{HTTP_HOST} ^stratavant.roi-selling.com$ to change with this
rewritecond %{HTTP_HOST} ^roi-selling.com$
???

A post with an ID of 2 is extremely common (by default, post 1 is the “Hello World” post and post 2 is the original “Sample Page” page), so it existing on the other site isn’t a surprise.

I checked both sites and they have different blog IDs in the tracking info, so that’s not the issue. I checked the redirected site in the Wayback Machine, and it had a different tracking code (as expected) too, for what it is worth.

The redirect rules shouldn’t make a difference either. Something is loading a page with an ID of 2 on a server that has your blog ID stored in the database. I’ve seen this most when someone is using a staging server, copied over the production database after installing/activating Jetpack, then visiting a page that exists on the testing server that doesn’t exist on the production one.

The development server is still the most likely target, in my opinion. I asked a number of coworkers to test the theory about the redirect and so far, haven’t seen a comparable increase in stats yet.

thanks for your reply….
we do not visiting to stage or development version now.
I will explain it again….
when I visit this link https://roi-selling.com/about-stratavant/
view count increase at here https://roi-selling.com/wp-admin/admin.php?page=stats with post/page title
And at the same time view count also increases for same visit at https://blog.roi-selling.com/wp-admin/admin.php?page=stats with #49(loading title).
And 49 ID is exists on main site https://roi-selling.com/wp-admin/post.php?post=49&action=edit .

If https://roi-selling.com/about-stratavant/ visit then count must increase on only here https://roi-selling.com/wp-admin/admin.php?page=stats not on second site https://blog.roi-selling.com/wp-admin/admin.php?page=stats Am I right???

For more details I am attach picture for the same.
1) I visit this page
https://www.dropbox.com/s/kt2fzba8mk6lm6d/Screenshot%202014-08-21%2015.20.50.png
2) view count increase here and it is right
https://www.dropbox.com/s/g2lyt9merrtjfrm/Screenshot%202014-08-21%2015.21.37.png
3) But In blog section view count also increases for same visit here
https://www.dropbox.com/s/9kene6yn2xckt0q/Screenshot%202014-08-21%2015.21.11.png

Simply I am visiting 1 page and view count increases on both site.
You said that both site have separate blog ID, then view count must be separate for each site.
Hope you understand…

Thanks for your patience.

Here’s what happened: Previously, it was requested that we merge the stats between these two particular sites. When we merge the stats, we add the “previous” or defunct site’s stats into the preferred site’s stats. Both still exist separately, but the “new” site displays the data for both combined.

In checking previously, there wasn’t as obvious numbering as there is at this exact moment (since hits to the new site with IDs match would have increased on that site and that site alone).

I’ve undone the merge so removed the incorrect views from the blog subdomain.

Please let me know if you have any other questions.

thanks issue is solved now…
Thank you very much..