Replies to This Discussion

Permalink Reply by Matthias Bettag on February 16, 2011 at 2:44am

The count is certainly on B as this is the source of the requested file. I would be surprised if A can count by default what is displayed in its frame (unless the frame content, hosted on B, is tagged in a way to be tracked by A).
In my understanding a count must not necessarily result in a pageview because a frame could display only a picture or a flash file, etc.

To answer your first question: I remember a situation where a webserver (B) almost broke down because one single (and too large) flash file was included in an framed advertising on a social community platform (A) with some 20mm views/day. The reason for the performance problem was detected by checking the webanalytics profiles for all websites hosted on B. So B had to manage the traffic which was caused by A.

I also know a well established domainname provider which uses frames for redirects (a very, very bad practice!). For a domain alias they use a one-page-website with the alias-URL, which HTML code was a single frame which included the site where the redirect should point to. This causes not only problems regarding SEO and Usability, but also costs webspace for the one-page-frame-website.

Frames, usually iFrames, can make sense for very specific use cases. But generally and especially for a website's own content I would not recommend it. But whenever iFrames are considered to be necessary, one should really make sure this does not cause any traffic/performance/measuring problems on the site where a frame's content is hosted.

Permalink Reply by Mike Kennon on February 16, 2011 at 9:42am

Generally the traffic when a page from site B is displayed in site A's frame, it is counted as a page view for site B and not for A.  When the page for site B is rendered in the frame, it is providing the java script that gets executed.  So whatever tagging script site B is using, that will determine where the hit is recorded.  If traditional logs are being used for tracking, the request for the page in the frame is made to site B so it gets recorded there.

 

This can be a problem.  The content delivered in the frame is a part of the user experience for site A.  If I'm trying to understand how users experience site A, activity on site B within A's frame is a black hole.  Frames frequently contain specialized processes or forms, possibly including my conversion form, but I have no visability into what the user is doing once they're in that frame.

 

Sometimes you can partner B so that they can create script to send a hit to your site, but as a part of that you would have to figure out a way to handle continuity of visitor identification.