> > Why not just bill per MB? I presume the processing is roughly linear with > the amount of data uploaded, so add a billable event for each upload that > tallies the amount uploaded. It'll be the largest billed portion > (bandwidth + storage) of the operation, and you can charge a nominal markup > on that to cover the CPU and datastore costs.
yes, that sounds reasonable. As I understand the billing, the upload will not be enough - I also need to check the data-storage that the customer currently uses: i.e. if they upload 1TB of data, then they need to be charged the storage cost of that 1TB until they delete it (maybe 2 month later, ..) BTW: how are the storage costs calculated in detail (I could not find this in the Billing FAQ)? e.g. what happens when a customer uploads 1TB of data on the 10th of the month and deletes it on the next day? of course they will be billed for the incoming traffic, but what about the data-storage costs (e.g. for the blob store it's some cent/G/month? i.e. if the storage costs are calculated only at the end of the month, this 1TB would not be seen and thus billed. or is the calculation done on a per-day basis or even shorter period? How *YOU* bill your customer does not have to be locked to how Google bills > you, only structured so it covers the costs and scales properly. exactly. On Tuesday, 9 April 2013 22:06:53 UTC+2, Chad Vincent wrote: > > Well, I think I see an easy method, here... > > Why not just bill per MB? I presume the processing is roughly linear with > the amount of data uploaded, so add a billable event for each upload that > tallies the amount uploaded. It'll be the largest billed portion > (bandwidth + storage) of the operation, and you can charge a nominal markup > on that to cover the CPU and datastore costs. > > How *YOU* bill your customer does not have to be locked to how Google > bills you, only structured so it covers the costs and scales properly. > > On Tuesday, April 9, 2013 11:07:27 AM UTC-5, Martin Trummer wrote: >> >> unfortunately a flat rate cannot be used, as we expect users to be very >> different: >> e.g. we might have big companies with several users that belong to one >> "billing-user" and this "billing-user" would need several TB per month and >> a lot of CPU time >> and on the other end of the scale we could have a single user that >> uploads only 1 MB per month >> so a flat rate is not feasible >> >> I am thinking of some basic rate for every user (which would cover some >> maintenance costs that cannot be assigned directly to a single user) plus a >> per-use fee (e.g depending on the uploaded/downloaded data, stored data, >> CPU cyles, etc.) >> The cost assignment need not be 100% accurate - we just want to make sure >> that we get at least the money from my users, that I have to pay to Google >> :) >> >> I've seen the appstats for Java: >> https://developers.google.com/appengine/docs/java/tools/appstats >> maybe I can somehow combine this with Google Analytics: >> http://www.google.com/analytics/ >> >> I am quite surprised, that AppEngine does not support something like this >> out of the box - or at least easy analytics integration. >> On the other hand, I understand that this is probably not a common use >> case. >> >> >> On Tuesday, 9 April 2013 17:23:32 UTC+2, Vinny P wrote: >>> >>> >>> On Monday, April 8, 2013 3:01:24 PM UTC-5, Chad Vincent wrote: >>>> >>>> You're going to have to take all your billable actions, log them to the >>>> datastore, and build a reporting framework. For datastore calls and email >>>> and such, this should be easy enough. I'm not sure if that would be >>>> possible for instance time, though. (Maybe with a Filter, and log the >>>> total amount of time each request takes internally?) >>>> >>>> >>> +1. Also, different actions have radically different costs; one user's >>> actions may only incur some Memcache/Task Queue/Logging operations, which >>> are free or relatively cheap, and another user may be searching the >>> datastore, which can quickly add up in costs. >>> >>> My suggestion? AppEngine implements the response header >>> X-AppEngine-Estimated-CPM-US-Dollars, which is an estimate of the cost of a >>> particular request times 1000 (Documentation: >>> https://developers.google.com/appengine/docs/python/runtime#Responses ). >>> This header is only available while you're logged in as an administrator. >>> So go browse your site, and build up a list of costs: what each page view >>> costs you. For example, maybe your home page only requires some memcache >>> data retrieval, so it should be charged very cheaply. But perhaps your >>> search page makes multiple calls to the datastore, so you charge more for >>> using that page. Then you need to record which pages your customers visit, >>> and bill accordingly. >>> >>> One side note: It may be easier on an administrative basis to charge >>> your users a flat fee instead of going through this hassle. Flat fees are >>> easier for users to understand, and they help reduce support issues >>> (witness the many cellphone horror stories where people accidentally go >>> over their minutes/text message quota and get hit with huge fees, nobody >>> likes those). Also, flat fees save you from writing billing systems and >>> allow you to concentrate on adding new features, which is presumably why >>> your users are paying you in the first place. >>> >>> >>> ----------------- >>> -Vinny P >>> Technology & Media Advisor >>> Chicago, IL >>> >>> @GOV on AppDotNet: https://alpha.app.net/gov >>> >>> >>> >>> >> -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/google-appengine?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
