Subscribe to DSC Newsletter

When a website A frames webpages from another website B, does traffic to framed paged of B (on A) appears in the logfiles of site B?

In Google Analytics, is it counted as traffic to A, or to B? Or to both?

An example of large scale "web framer" is LinkedIn. This could artificially inflate their page view counts (reported to Wall Street each quarter when they go public), since a user on a framed page is actually not looking at LinkedIn content, nor does he/she believe to be visiting LinkedIn, but rather, the framed page which is externally hosted. Could this potentially create liability / litigation? Are there technical ways around this, to prevent framing?

Views: 80

Replies to This Discussion

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.

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.

RSS

On Data Science Central

© 2021   TechTarget, Inc.   Powered by

Badges  |  Report an Issue  |  Privacy Policy  |  Terms of Service