Live data from Hacker News

Google Web Fundamentals: Monetization

developers.google.com

11–20 of 60 posts

Re: Google Web Fundamentals: Monetization

#11
post #9

Earlier quoted context omitted.

I would like to ask how these recommendations are reached. Meaning, can you show hard data that backs up the assertions on how people buy, etc.? I am not trying to snipe you or the site. I appreciate the effort. But in my experience Google recommendations (with Adwords or Adsense or which reports I should see) mean almost nothing and I rely entirely on my own data. For example, the first article on the first page 'Le…

Urgh, that is a url encoding error on our site. I have raised a bug ( https://github.com/google/WebFundamentals/issues/664 ). With regards to the study, that data was ascertained by working with direct user studies and taking feedback from them, I think we can certainly make this a lot clearer in the those set of documents. re:sparse. Yes it is as we are still building this section out and fleshing out the guidance m…

I look for two basic things:

1. Where did people come from and how did I convert them?

2. What is my conversion/impression/sales, etc. for the month/quarter and how does that compare to previous month/quarter or a specific date?

So, what I mean is if I have an event coming up and I am marketing to that event - I have email lists, twitter accounts, FaceBoook, a popular blog, co-op email partners, and I buy ads on multiple platforms...I want to know how many people came from each source, what the conversion rate was, how far they got in the process, and I want to see how this year's event is comparing to last years'. Or last months'. Or last weeks'. Or an event I had three quarters ago.

I need the data to be as accurate as I can get, because if people are coming into the site, and all of the ones coming from, say, Twitter, are not buying and don't even read anything, then I need to know that.

As an example, for a sports event I run in the summer, two years ago I dropped PayPal as an option entirely. I had so many complaints from consumers about PayPal in general I just decided to implement Stripe. A lot of people told me that since PayPal is so ubiquitous, I would be cutting out an ease-of-payment option and I would lose sales.

But my data showed two things: a lot of people DID use PayPal but I lost a ton of conversions when people hit the PayPal page AND my #1 complaint topic was PayPal related. About 60% of the people who signed up used PayPal.

Both of the last two years after implementing Stripe my conversion rate increased dramatically and I have ZERO complaints about the payment process. Literally, zero.

So that's what I'm always looking for. How do I optimize and track turning people who are searching into customers without wasting their time or my time? How do I remove frustration for users? Where do they navigate to? If they hit a specific page and then suddenly jump around looking for a 'contact us' page, I need to figure out what those people are looking for and fix it for them.

With Google analytics or adwords, I get some data but a lot of it other than a few pieces is superficial or the data doesn't match my server logs.

Sorry for the digression.

Re: Google Web Fundamentals: Monetization

#12
Regarding the article 'Let Users Explore Before They Commit' -

This is much easier said than done, and the effort and complexity will vary greatly depending on your site/app. The example used (nondescript clothing app) is one of the simpler cases, whereby the cross-session and device user-state need not be maintained, or is at least pretty minimal.

For many app developers, though, the richness of their feature-set doesn't come across until the user has a detailed state, such as level achieved, past activity, preferences, etc. Without asking users to "commit", sites/apps need to associate state with an anonymous user.

Unfortunately, it's not quite trivial to maintain the concept of an anonymous user. For one, the lengths the mobile industry is going to restrict the use of unique device identifiers poses a complexity to identify the same device across sessions. Moreover, anonymous users pose an issue for services with a value proposition behind their cross-device/platform support. Also, for small sites, it may not be trivial to introduce a data-model that supports anonymous data, which either needs to be thrown out or eventually merged with account-linked data. Similarly, 3rd-party engagement and funnel analysis of anonymous users is also a hard problem, as when the user does eventually identify themselves with an account, you need to merge their previously anonymous data into their account. Some services call this Aliasing.

I'll echo other comments that the content is sparse - this section specifically speaks as if registration count is the sole goal of the target audience. A comprehensive document would account other conversion-like goals that site/app makers might have, and the weigh the cost-benefit analysis of requiring registration.

Re: Google Web Fundamentals: Monetization

#14
post #12

Regarding the article 'Let Users Explore Before They Commit' - This is much easier said than done, and the effort and complexity will vary greatly depending on your site/app. The example used (nondescript clothing app) is one of the simpler cases, whereby the cross-session and device user-state need not be maintained, or is at least pretty minimal. For many app developers, though, the richness of their feature-set do…

I've found a no-questions-asked refund policy for the first few days of the account much more satisfactory than trial or free accounts.

Re: Google Web Fundamentals: Monetization

#15
post #12

Regarding the article 'Let Users Explore Before They Commit' - This is much easier said than done, and the effort and complexity will vary greatly depending on your site/app. The example used (nondescript clothing app) is one of the simpler cases, whereby the cross-session and device user-state need not be maintained, or is at least pretty minimal. For many app developers, though, the richness of their feature-set do…

We are certainly planning on making these sections more comprehensive. This is just the first iteration of this and as we get more feedback and we create the deeper guidance this will certainly grow. The way this is presented right now is "people found this experience frustrating, don't do it." We need to dive more into "these are 2-3 patterns that we know work really well.". A lot of feedback we recieved is that actually a lot of developers want the seed of the guidance first, specific guidance a little later.

I think you hit the nail on the head about anonymous users. It is hard, and there are patterns that we have not fully explored yet such as sign in on add to checkout.

Re: Google Web Fundamentals: Monetization

#16
post #2

One of the authors of the site here. We are very keen to get feedback on the content that web developers want to see with regards to monetization. For example one area that I am keen to see us grow is building components in sites that optimize credit card data entry.

Here's some feedback: I think it's incredibly cool you put that site out on Github even though you clearly did not have to. Keep doing that. :)

Re: Google Web Fundamentals: Monetization

#17

I would be loath to take advice from Google about how to monetize a small website. Not just because of the conflict of interest (of course they want people to run ads), but because it's not their area of expertise.

I think traditionally that is something that rings true. Ads aren't the only answer and this is just the first step in a more comprehensive area that we are planning. I would say that one area that we get a lot of requests for from web developers is strong guidance on how to build forms that convert well. We have data on this, we just haven't formalized the guidance on this.

Re: Google Web Fundamentals: Monetization

#18
post #9

Earlier quoted context omitted.

Urgh, that is a url encoding error on our site. I have raised a bug ( https://github.com/google/WebFundamentals/issues/664 ). With regards to the study, that data was ascertained by working with direct user studies and taking feedback from them, I think we can certainly make this a lot clearer in the those set of documents. re:sparse. Yes it is as we are still building this section out and fleshing out the guidance m…

I look for two basic things: 1. Where did people come from and how did I convert them? 2. What is my conversion/impression/sales, etc. for the month/quarter and how does that compare to previous month/quarter or a specific date? So, what I mean is if I have an event coming up and I am marketing to that event - I have email lists, twitter accounts, FaceBoook, a popular blog, co-op email partners, and I buy ads on mult…

No worries about the digression. This is great!

We are working on getting an analytics section built for this that is just not Google Analytics but also guidance on things that you should be monitoring, why they are important and how to use that information to change your product. I see the analytics and the monetization section actually being quite tightly integrated when we can land it.

Re: Google Web Fundamentals: Monetization

#19
post #2

One of the authors of the site here. We are very keen to get feedback on the content that web developers want to see with regards to monetization. For example one area that I am keen to see us grow is building components in sites that optimize credit card data entry.

Here's some feedback: I think it's incredibly cool you put that site out on Github even though you clearly did not have to. Keep doing that. :)

Thanks! The repo is starting to gather a lot of infrastructure cruft that we need to sort out, but we are getting there :)

Re: Google Web Fundamentals: Monetization

#20
post #4
post #3

It's too bad the Google+ team never saw this document.

How does this improve the conversation?

It points out the vast discrepancy between what Google recommends people do and what they actually do, suggesting that they are either ignorant of best practices, or are lying about best practices.
Post reply on HN