Do Google Analytics virtual pageviews have to be urls? Are any other string formats valid, and are the allowable formats documented?
As far as the documentation goes, I am not sure if there is one. In fact if there actually needs to be one as there is just one STRING parameter you need to use. And it can be "anything" (for example: '/downloads/dynamic-form') that would supplement a unique URL which cannot due to some technical reason used but would make sense to include as a seperate page-view within Google Analytics report.
Example of use virtual pageviews:
_gaq.push(['_trackPageview', '/downloads/dynamic-form']);
There is however a lot of use-cases where Events would do a better job, as tracking virtual pageviews "will add to your total pageview count" (see the official GA documentation). For example downloads, outbound links, buttons etc.
Be careful with using Events however, as there are some limitations as well and make sure you specify whether it is an interaction or non-interaction event (this has impact on other reports like Bounce Rate and etc.).
Related
I've skimmed through the Keywords Performance Report of the API documentation, and couldn't understand whether it would be possible for me to use this report to determine daily keyword costs.
What I want is basically to be able to look for keyword to an API request result and get the cost associated with it. Is such a thing possible? Am I looking in the right place?
Apparently, it's not possible to do so, since all costs on all Display Network items are listed with a special ID (3000000) in costs, meant to capture all GDN displays.
We have a requirement to capture the number of users who successfully logged in or updated his/her profile.
On reading about this, we see that events are the right ones to use to capture this metric.
Just wondering, why can't we use the s.pageName to know the number of successful logins? We set a particular pagename to that variable, and the count of that page name tells us the number of successful logins or updated his/her profile.
You can create a calculated metric for your count of page views on the success page in Adobe Analytics as an alternative to capturing an event.
They are just different and have different advantages.
One reason using events can be helpful is that you could track an event across multiple domains or if you want to track different types of registrations (popup vs checkout). My employer runs dozens of websites and events are very useful to track errors across domains or checkout events.
Using a calculate metric can be very powerful as well. The biggest strength here being that (hopefully) you have been tracking pageNames since day one. If you use an event to add tracking, you will get tracking from the day you tagged it. If you use a calculated metric, you will be able to retroactively see data from years past.
Generally, we use a calculate metric in most cases where it doesn't provide any data issues.
A week ago Buzzfeed announced a new viral traffic tracking tool called "Pound" (Process for Optimizing and Understanding Network Diffusion). Whereas marketers and webmasters are currently used to seeing social traffic in aggregate buckets per source, Pound promises to help us visualize the actual person-to-person sharing of content and the traffic resulting from each step... sorta, apparently the tool can't (or opts not to) match individual users to their corresponding node in the network:
Pound does not store usernames or any personally identifiable information (PII) with the share events. Each node in the sharing graph is anonymous. We are not able to figure out who a user is by looking at the graph data.
Interesting. I assume Buzzfeed is keeping this anonymous to preempt complaints when the company uses Pound to sell ads. More interesting, the hint the Buzzfeed engineers provide as to how this tool works:
Pound data is collected based on an oscillating, anonymous hash in a sharer’s URL as a UTM code.
How might this work? Does the UTM code mutate every time a link is shared or reshared? I don't understand how this is possible. If it's not, how might this functionality be possible?
I'm working on a project that returns information based on the user's location. I also want to display the user's town in text (no map) so they can change it if it's not accurate.
If things go well I hope this will be more than a small experiment, so can anyone recommend a good reverse geocoding service with the least restrictions? I notice that Google/Yahoo have a limit to the number of daily queries along with other usage terms. I basically need to take latitude and longitude and convert them to a city/town (which I presume cannot be done using the HTML5 Geolocation API).
Geocoda just launched a geocoding and spatial database service and offers up to 1K queries a month free, with paid plans starting at $49 for 25,000 queries/month. SimpleGeo just closed their Context API so you may want to look at Geocoda or other alternatives.
You're correct, the browser geolocation API only provides coordinates.
I use SimpleGeo a lot and recommend them. They offer 10K queries a day free then 0.25USD per 1K calls after that. Their Context API is what you're going to want, it pretty much does what is says on the tin. Works server-side and client-side (without requiring you to draw a map, like Google.)
GeoNames can also do this and allows up to 30K "credits" a day, different queries expend different credit amounts. The free service has highly variable performance, the paid service is more consistent. I've used them in the past, but don't much anymore because of the difficulty of automatically dealing with their data, which is more "pure" but less meaningful to most people.
I work for a publishing house and we're discussing different ways to sell our content over digital channels.
Besides the web, we're closely watching the development of content publishing on tablets (e.g. iPad) and smartphones (e.g. iPhone). Right now, it looks like there are four different approaches:
Conventional publishing houses release Apps like The Daily, Wired or Time Magazine. Personally I name them Print-Content-Meets-Offline-Website Magazines. Very nice to look at, but slow, very heavy regarding datasize and often inconsistent on the usability side. Besides that: These magazines don't co-exist well in a world where Facebook and Twitter is where users spend most of their time and share content.
Plain and stupid PDF. More or less lightweight, but as interactive and shareable as a granite block. A model mostly used by conventional publishers and apps like Zinio.
Websites with customized views for different devices (like Die Zeit's tablet-enhanced website). Lightweight, but (at least until now) not able to really exploit a hardware platform as a native app can.
Apps like Flipboard, Reeder or Zite go a different way: Relaying on Twitter-, Facebook- and/or syndication-feeds like RSS and Atom, they give the user a very personalized way to consume news and media. Besides that, the data behind it is as lightweight as possible, the architecture to distribute the data is fast and has proven for years to be reliable.
Personally, I think #4 is the way to go. Unluckily the mentioned Apps only distribute free content and as a publishing house we're also interested in distributing paid content.
I did some research googled around and came to the conclusion, that there is no standardized way to protect and sell individual articles in a syndication feed.
My question:
Do you have any hints or ideas how this could be implemented in a plattform-agnostic way? Or is there an existing solution I just haven't found yet?
Update:
This article explains exactly what we're looking for:
"What publishers and developers need is
a standard API that enables
distribution of content for authorized
purposes, monitors its use, offers
standard advertising units and
subscription requirements, and
provides a way to share revenues."
Just brainstorming, so take it for what it's worth:
Feedreaders can't do buying but most of them have at least let you authenticate to feeds, right? If your free feed was authenticated, you would be able to tie the retrieval of atom entries to a given user account. The retrieval could check the user account against purchased articles and make sure they were populated with fully paid content.
For unpurchased content, the feed gets populated with a link that takes you to a Buy The Article page. You adjust that user account and the next time the feed is updated, the feed gets shows the full content. You could even offer "article tracks" or something like that where someone can by everything written by a given author or everything matching some search criteria. You could adjust rates accordingly.
You also want to be able to allow people to refer articles to others via social media sites and blogs and so forth. To facilitate this, the article URLs (and the atom entry ids) would need to be the same whether they are purchased or not. Only the content of the feed changes depending on the status of the account accessing the feed.
The trick, it seems to me, is providing enough enticement to get people to create an account. Presumably, you'd need interesting things to read and probably some percentage of it free so that it leaves people wanting more.
Another problem is preventing redistribution of paid content to free channels. I don't know that there is a way to completely prevent this. You'd need to monitor the usage of your feeds by account to look for access anomalies, but it's a hard problem.
Solution we're currently following:
We'll use the same Atom feed for paid and free content. A paid content entry in the feed will have no content (besides title, summary, etc.). If a user chooses to buy that content, the missing content is fetched from a webservice and inserted into the feed.
Downside: The buying-process is not implemented in any existing feedreader.
Anyone got a better idea?
I was looking for something else, but I've came across with Flattr RSS plugin for WordPress.
I didn't have time to look it through, but maybe you can find some useful ideas in it.