I've gone through all the GA documentation and understand pretty well how to track across subdomains. I need to do something slightly different. My sites are moving from subdomains to subdirs onto one subdomain (www). From site1.domain.com to www.domain.com/site1, etc. Previously, there was nothing on www, only the subdomains, which all have their own tracking id, ie. 12345-2, 12345-3, etc. Both sites (old and new) will be live at the same time, so we need to aggregate and track across the subdomains (got that down, w/ all the filters needed) but also track/link only a specific directory on the www to each of the old subdomains. One kink is that while all the sites will map easily from site1.domain.com -> www.domain.com/site1, one special site - online.domain.com will map to www.domain.com/ with no subdir.
I figured I could solve the subdir issue by only placing the code for each property id on the respective subdir pages. I.e. site1=12345-2, and all the pages in /site1 get that code. For the online.domain.com site, the property-id specific code would have to be added to about 20 other subdirs, like /about/, /contact/, etc. Is this correct or kludgy? And i might even add new profiles that filter for subdir as a backup measure. But the issue I am having is this, I really want to track them as separate sites so that referral, time on site, etc metrics are specific to each subdir (site) and not shared across all the subdomains (which I think what subdomain cross tracking enables.) So I thought the solution was _setCookiePath, but can I use that on one subdomain (www) while cross-tracking and not the other? Because the old site won't have /site1/ as a valid path. Logically, is this something I even can do? Won't setting _setCookiePath on one side defeat the purpose of cross subdomain tracking?
I am confused about the usage of _setCookiePath when tracking subdirectories. When do you use setCookiePath and when do you just filter the data via subdir with profiles? The documentation says if you use _setCookiePath you need to disable tracking at the root level. What is the issue there? (I don't think this would work for me because I also need to track other top-level dirs like /about/). Also in another rollup account I want to track all the sites with one property id and then use filters to set up unique profiles for each subdir/site, eventually retiring the old method that uses multiple profile IDs. But I want to track my subdirs as separate sites with separate cookie info so that a referral to www.domain.com/site1 is not shared with www.domain.com/site2 - is this impossible with my requirements? More importantly, visits and uniques need to be segmented by subdir. A user that comes to /site1 then goes to /site2 needs to be a new visitor on /site2.
Update: did I totally overthink this? Since users probably wont be moving between old and new sites can I just add the same tracking property id to both sites w/o crossdomain tracking? That would help me consolidate old and new, but I still have the issue of how to track all the new subdir sites as different sites that don't share cookie info.
It sounds to me like you are moving from a more complex set up to a far simpler one.
If your new domain structure is:
www.site.com/one
www.site.com/two
www.site.com/three
www.site.com/four
Then the standard default Google Analytics code snippet will work. IE Without cross domain tracking, just select 'single domain' when setting up your new profile.
The only issue i can see is that current your data is stored in different profiles. Using this new setup all data will be stored in one single profile. However using the 'Page' metric you could create advanced segments to separate traffic visiting 'Pages' beginning with '/one' for example. Or you could create multiple filters with Page based filtering to separate the traffic from 'www.site.com/one' from 'www.site.com/two'.
Related
It seems that a company from Korea downloaded our front-end html/CSS files and built a website, but they did not bother to remove our UAT number and now our analytics are full of misleading traffic from their website. Already contacted them to remove it but is there a way to exclude entirely the data from that domain?
At view level, you can use a custom filter to block it. You've got a few pre-set options on what to block - by hostname or by country, or an entirely custom definition. This won't back-date, a segment with the same sort of filters will do it for existing data.
A hostname filter is probably the best if it is a single website that has copied your code. As mentioned above, it will not back-date
I have forum directory on my website. That sub directory is located on http://www.mobilestore.pk/forum I was wondering that how can I track forum traffic only as a separate property in Google Analytics without filtering it from the whole traffic of the website. So I can show the trends of forum to Moderators or Editors.
I don't recommend using a property to break out traffic on the same domain. It's better to use a new view with a filter. Be sure to keep a view that is unfiltered.
If you do decide to use a separate property, you will need to modify the code in all the page templates used in the /forum path to use a different UA tracking ID.
You can add a 2nd tracker for just the forum.
As per Google:
"In some cases you might want to send data to multiple web properties from a single page. This is useful for sites that have multiple owners overseeing sections of a site; each owner could view their own web property."
This exactly fits your scenario
See https://developers.google.com/analytics/devguides/collection/analyticsjs/advanced#multipletrackers
I am developing a site in Wordpress that offers functionality and content to companies.
Each company will have hundreds of users. All users of all companies get the same content.
However, the main header changes (it needs to include the companies own logo). They also will have their own sub-domain, at least fo the login page, preferably for all pages.
The content will change regularly, so I would prefer having only one copy of that.
So the requirements are:
Same content for all users at same relative url
Different header based on group of current user
Different base url per group
forwarding of user to the correct base url if they login under a wrong one
What is the best way to implement this?
Straight WP with a sub-theme that deals with the header. Mod-rewrite to deal with the urls
WP-MultiSite (how would the same content under different base urls work here?)
Several copies of the site and somehow sync the content (how would I do the sync?)
Use a different CMS
Which of these is the most future proof way to go, assuming I might have to deal with thousands of companies each with hundreds to thousands of users.
Also, If there is an easier way because I missed something in my research like an existing plugin, that would be great too.
Thanks for your help.
I would say that such a thing depends on a lot more than these requirements. For instance, how granular would you like to have your user management? And how much are the users allowed to do on the different groups? Is unique information allowed on the different domains, or is all the information shared?
Based on the information you are providing, I think youy would be best off using the multisite version of wordpress. You then could use a broadcast plugin to share the information on all sites, and create a template site from which to create new sites (using the NS cloner plugin for instance).
There are of course some problems with this approach, for instance search engine optimisation. You will get a lot of duplicate content that will hurt the google ranking of the individual sites.
It would also be possible to do this using a single site install, but then you'll run into problems with the multiple domain structure. It can be done, but the available caching plugins will not support it (at least not that I know off), whereas a multisite environment is supported out of the box. It is also more difficult to keep users from posting on different domains, as they are using a single install. A multisite environment also has as shared user base, but they can be added or removed from the different sites at will.
Using a multisite environment would also allow you greater flexibility template-wise.
I want to track traffic for mysite.com/current-campaign/ and careless about traffic on mysite.com in general.
Is it ok to place the GA tracking code in the files inside the /current-campaign/ folder or does it HAVE TO be in the root of the server for tracking to work?
GA will only track on the pages you actually put the tracking code on, regardless of where the page is located (unless you start messing with things like domain settings or filters etc..).
So IOW yes, it is okay to do that. If you don't have tracking code on mysite.com/somePage.html then it's not gonna track that page (though it might show up as the URL in some reports like referring URL or exit link or whatever, same as any other page you don't track)
In Google Analytics, you can add a filter to the profile and filter all but the chosen directories. Go to Analytics Settings > Profile Settings and look for "Add Filter" link.
In addition to Crayon's answer, you can limit tracking to a subdirectory by using _setCookiePath() function in your tracking function. See Analytics documentation on single subdirectory (note the link anchor is not resolved to a correct header, at least for me).
This is advised in the documentation to use when you only want to track a subdirectory and avoid clashes with Analytics trackers possibly in use in other subdirectories.
I work for a department in a large university.
The department's web page resides at www.some-uni.com/department-name/.
I only have FTP access to the sub-folder /department-name/ and nothing else on the site.
It was quite easy to get Google Analytics to track traffic within the subfolder /department-name/, ignoring the rest of the site. All I did was create a profile in GA, setting the default url to www.some-uni.com/department-name/. I then pasted the tracking code into the pages I wished to track.
It took about eight hours for anything to show up in GA, but after that it worked just fine.
I want to move a drupal site to another domain and am looking for best practices, gotchas, hint, tips, etc to make sure I get through it smoothly.
Links and comments are appreciated.
You might want to give a try to the Backup And Migrate module.
There is also this handbook page that gives instructions on how to backup your drupal site.
It took me 1-2 hours. I do not have a step-by-step guide (I wish I had written everything down), but it entails updating the configuration files, updating the database (some tables have domain references, but I don't recall which - it could be that this was just for my image references in the Gallery2 database), and doing a cursory search of the content for full domain references in anchor links.
I migrated a Drupal 6 site with about 40 plug-ins, including Gallery2 and Google Maps integration, and I did not run into any major road blocks.
If you (and the authors of the contrib modules you used) did a good job by not putting absolute URL's in the code, it should be dead easy (I do it routinely when migrating the development site to a live production one, for its launch).
Of course I assume that you are doing things sensibly, and for example are not migrating a site from an apache/mySQL server to a nginx/postgres one, maybe also adding the need to prefix your DB tables in the process.
If this is the case, then you simply have to copy your entire file tree and export/reimport your DB.
If you are migrating between two similar architectures then chances are you will only have to change a few things in the settings.php file. The file is well documented. The only two things that I normally have to change are:
DB user/pass
cookies domain
In the file there are also additional configuration options like the possibility to choose the base URL manually in case of problems.
Don't forget to flush the cache once you log in the new migrated site for the first time.
EDIT: Just came to my mind: if you use any, you will also have to update your developer keys to third party API's (for example if you use google maps or google analytics) as these are domain specific.
HTH!
Basically, what mac said (+1)
In addition, I often need to adjust the .htaccess files a bit concerning the rewrite rules. For smaller sites on shared hosting environments, I usually place the drupal installations in subfolders within the document root (e.g. to allow for staging, etc.), 'hiding' the subfolder via URL rewriting. So for every 'move' of a site, I need to fix those rules.
The biggest culprit for me are sites that use modules that have to store absolute URLs in order to do their job (e.g. securepages). For those you should disable them prior to moving the site, adjusting their settings before reenabling.
If you are not sure if some of the modules you use store absolute URLs, it might pay of to extract your database dump locally and search the resulting file for occurrences of 'http://', 'https://' and the likes, as well as for your 'old' domain name (you'll need to exclude the watchdog and cache tables for this).