Intermediary transaction SEO diagnosis Taobao guest Cloud host technology Hall
Objective】
Recently busy East tour west, so busy in the time to write something is not easy, temporarily do not prepare long text, we look at also relaxed point. In the United States for a period of time, not unpatriotic, but quite like this country, especially strangers to meet you smile dour hello how to are you, feel warm in a foreign country. Cough, I'm a little reluctant.
I'm not going to talk about the report for the time being. But to start a new topic, talk about the monitoring of web site analysis implementation, because recently also in the field of learning, reminded some memories, think of their own just started the site analysis of those who committed small mistakes, just comb the time. Originally prepared an article on the finish, the results of a write, found not so simple, so have to open the next chapter.
Body】
Website analysis is able to achieve analysis, is to obtain the site visitors behavior data. However, I have never encountered a situation where I have achieved all the data needed for analysis by 100%. Believe me, no, never, no matter who is unable to do, because some things are later aware, you can not fully anticipate the data you need beforehand.
However, this does not mean that you can give up the pursuit of more comprehensive and accurate data, and Napoleon could not anticipate all the details of the battles he would face every time, but he did not make the best preparations beforehand. You are also a website analysis of the generals, so you need to do the best in advance, otherwise it is likely to the site analysis of the station above the defeat.
Therefore, it is undeniable that the monitoring of Web site analysis is very important, even more important than how to analyze itself.
Now, I'm going to talk about some of the pitfalls I've often encountered in the implementation of analytics, some of which may be commonplace, but valuable to beginners. Note that each of the following can be used as a scan list to check the site before it is implemented, and at the end of the series I will also make a list of site implementation preparations. In addition, I summed up the affirmation is not comprehensive, I hope you can continue to add in the comment box, thank you!
Trap One: cross-domain monitoring
This is the website analysis implementation time Most easy to forget the question, I first time to do, completely did not know has such a thing, now thought that was very silly at that time.
Cross-domain monitoring is a problem for Google Analytics, and Omniture is not worried (of course, it has other areas similar to the area to note). For Google Analytics, if you want to put all of the monitoring results of different domains (domain) or subdomain (sub-domain) in a report set (profile), then you can't just put the standard code that is not handled directly on each page.
For example, if the three primary domains of chinawebanalytics.cn, chinawebanalytics.com, and chinawa.org are logically actually a Web site, and you want them to be present in a collection of reports, you need to do cross-domain processing when monitoring implementations.
The method is simple enough to choose the right code to add to the page. As shown in the following figure (click to see larger image):
I'm sure you know where this screenshot comes from.
However, because of the lack of monitoring across the primary domain, many times we do not fall into this trap. We often have problems with cross domain monitoring because we mistakenly assume that this is not a special case.
Subdomains such as: blog.chinawebanalytics.cn and www.chinawebanalytics.cn, belong to chinawebanalytics.cn this primary domain, but we also want to give them special code, otherwise some of the data will be confusing. For example, data such as referrer,bounce rate such as blog.chinawebanalytics.cn and www.chinawebanalytics.cn will appear in traffic source. Quite a portion of your data has been destroyed, and there is basically no critical analysis.
The method is the same as the above, as shown in the following figure (click to see larger image):
Trap Two: Reporting structure
Since it involves cross-domain and cross-domain issues, if you think about it, you'll have a problem with the reporting structure. What is a reporting structure? First, for example, you'll see.
Suppose there is a large site, such as sony.com, which has sites in various regions, such as china.sony.com, japan.sony.com, gemany.sony.com ...; It also has a variety of product segmentation sites, such as psp.sony.com, notebook.sony.com, movie.sony.com ...
Assuming that you are the director of the website optimization Department of this company (a good position, isn't it?), your internal clients include the CEO, the general manager of each region, and the general manager of each product department, and they all want to know what value the site brings to them. How do you monitor the site in order to successfully answer their questions?
This involves different ranges of reporting. For the CEO, we must at least give him a global report, because only he and a handful of people (including yourself) need to see the full picture; for the bosses of each region, they just have to know the site of their own area, and for the heads of each product department, they look at their own product sites.
Now let's assume that the Web analytics tool we use is Google Analytics, which can get at least four solutions:
Solution One (this method is a trap we fall into easily)
Build a separate profile for each child station. The disadvantage of this method is not a whole station profile, so in order to get the whole station, you can only manually add total sum calculation. You mustn't do that.
Workaround two (this method is also a big trap)
For the whole station to build a profile, of course, has paid attention to the problem of cross-domain. The disadvantage of this method is not a single station independent situation, such as psp.sony.com bounce rate is how much? The way to solve the problem is to take your own data and slowly compute it. This method can be quite sad.
Workaround Three
is to add at least two sets of code for each site: A set of unified code for the whole station, to establish a general profile, with the solution three; the second set of code is the code of each child station, so that there are separate reports of the child stations. This method compared to the front, consider a lot of comprehensive, can solve the needs of different users. But the imperfect part is that code implementation is complex and redundant, so it is not the most optimized method.
Workaround Four
This is the best way I think. The reason is that I can use a set of code to achieve both the overall and the subdivision of the report (profile), we do not interfere with the data accurate. How do you do it?
We first build a profile from GA and get a set of code that is monitored across subdomains. Then, implement this code on all pages of the site. After that, the real tricks began. We copy the newly established profile in the settings background of GA report, how many stations are copied, then, do the filtering, leaving only the traffic of each station, the filtering method please see here.
In fact, this solution is Google Analytics implementation of one of the introductory lessons, please click here to learn the official information, I highly respected Oh!
The above solution is Google Analytics, for the Omniture, the idea is exactly the same, and the method is similar, for different sites to create different report suite, to achieve different site coverage of the reporting division.
At the end of this trap, I would say that the site monitoring structure is really important because it can satisfy all departments, and it can also give you a power of happiness-because only you have all the secrets.
Trap Three: Page dynamic event monitoring
The so-called page dynamic events, the interactive elements that we often say are not HTML links on the page, including buttons or links in Flash/flex, JavaScript, AJAX, SilverLight, dynamic events in HTML5, etc., such as the " Watch Now> "is a flash button. User access to these dynamic events, the behavior can not directly through the standard code to obtain monitoring data, so need to make certain of the monitoring Code customization.
The trap in this place is that we don't know what to do with additional customized monitoring, and secondly we are prone to monitoring implementation errors.
In Google Analytics, there are two ways to monitor a page's dynamic events, one called Virtual page, and the other is called event tracking, which is incident tracking. In the previous approach, the click of these dynamic events was the same as opening a new page, and the latter approach was to separate these events as a special case in the event tracking report of the specific content.
The Virtual page method needs to use the _trackpageview () function to solve the problem, the syntax is: "_gaq.push ([' _trackpageview ', '/events/playvideo ']);", after that, This event appears in the top content report in content with/events/playvideo as the page name.
When implemented, place the _trackpageview () function in the onclick (or onrelease) event of these dynamic events, and if you do not know how to add, your site's front-end it colleagues must understand that it is not a big problem to consult them.
The virtual page method is simple, but the biggest problem is inflate (virtual) "Top content" report data, and the ability to monitor the behavior of the property is just click one, do more detailed analysis is not enough.
To make up for this flaw, Google Analytics has developed another, more advanced feature, which is no longer the mysterious event tracking function, the syntax is: "_gaq.push" ([' _trackevent ', ' Category ', '] Action ', ' readable ', value], "is also added to the onclick (or onrelease) event, very similar to the method of adding virtual page.
For these two features, GA official also has instructions, please click here.
The reason we recommend this feature is:
1. Event tracking will not put the data in the top content report, which will not confuse the report. It has its own independent report, as follows:
2. The many properties of event tracking are useful, especially the addition of the attribute "value", through which we can assign different weights (weight) to different dynamic events, so that the indicators index can be calculated automatically.
3. The addition of attributes also brings more potential for subdivision analysis. We are able to strengthen the analysis of the page (or whole station) dynamic events accordingly.
However, all pros and cons, because of a number of attributes, so friends sometimes easy to make a small mistake, these errors have been mentioned in the Tenly article (please note that this article is based on GA old code, the new code has been updated Pagetracker object is: _ Gaq.push, but nothing else has changed. If you haven't tried the event tracking's child's shoes are worth reading this article.
Another drawback is that the event tracking is not pathing, that is to say, can not understand the path between them and the relationship between the page, but only a simple count. The function of virtual PageView can obtain pathing function, although can't say very accurate, but better than nothing. The choice depends entirely on your prior monitoring needs.
Also, note that sometimes we will add this function to the first frame of flash, resulting in the page (on Flash) loaded in the same time, will automatically run this function, rather than the visitor clicked on a dynamic event to run, which is actually monitoring the implementation of the accident.
Finally, event tracking because it contains multiple attributes, so you need to pay attention to the consistency of the naming rules, if events are registered, then throw them all to registration's category instead of having registration name, and the name of the register. Otherwise the report is not so good read.
Well, the last section of the book, although it is a very basic content, but we may still have a lot of problems, now time for you, please reply to me in the message box!
The pitfalls we'll cover in the next section include: Outside chain monitoring, code conflict, jump, frames page, custom fixes, and more. Stay tuned!
Original address: http://www.chinawebanalytics.cn/wa-implementation-trap-1/