- copy protection doesn't work - apps get hacked and redistributed
within 24 hours
- users backup apps to sdcard, refund and reinstall = no payment to
dev
- payments fail on international orders
- most countries still excluded from paid apps
The 4 issues above mean that for every sale that a dev is only
achieving a low percentage of sales he or she has earned - maybe as
low as 30% although this is obviously just a guess.
Google please fix so that app devs are motivated to make better apps
rather than have their work stolen or simply unavailable to users who
want to buy (which only fuels the illegal market further).
And yes I have listed on alternative markets - but the experience so
far is that most users give up after attempting purchase on primary
market.
I'll give you some then. Right now my app has 70% retention after
purchase. So it's the reverse of what you say. I have 30% of people
return it, everyone else keeps it and I get paid. I don't think that
is too bad. And yes, I have found my app on pirate sites, but I do
lots of new features every month or so. Those pirates haven't kept up
with that at all.
-niko
On Oct 29, 4:46 am, "admin.androidsl...@googlemail.com"
<admin.androidsl...@googlemail.com> wrote:
> Biggest market issues for me are :
> - copy protection doesn't work - apps get hacked and redistributed
> within 24 hours
> - users backup apps to sdcard, refund and reinstall = no payment to
> dev
> - payments fail on international orders
> - most countries still excluded from paid apps
> The 4 issues above mean that for every sale that a dev is only
> achieving a low percentage of sales he or she has earned - maybe as
> low as 30% although this is obviously just a guess.
> Google please fix so that app devs are motivated to make better apps
> rather than have their work stolen or simply unavailable to users who
> want to buy (which only fuels the illegal market further).
> And yes I have listed on alternative markets - but the experience so
> far is that most users give up after attempting purchase on primary
> market.
I agree with the points above, and would like to add another
issue. For my app, discovery is the main issue. A developer could
come up with a great app, but no one will ever see it. Only when it
is published, it is listed on the top of the "Just In" list. Half a
day later, it is gone way down on the list. There is a search
function, but that means the user must know what to search for in the
first place. There is a need for subcategories, below the 10 top level
ones, so people can browse, and see all the different types of
applications that are offered.
Nitin
On Oct 29, 9:57 am, niko20 <nikolatesl...@yahoo.com> wrote:
> I'll give you some then. Right now my app has 70% retention after
> purchase. So it's the reverse of what you say. I have 30% of people
> return it, everyone else keeps it and I get paid. I don't think that
> is too bad. And yes, I have found my app on pirate sites, but I do
> lots of new features every month or so. Those pirates haven't kept up
> with that at all.
> -niko
> On Oct 29, 4:46 am, "admin.androidsl...@googlemail.com"
> <admin.androidsl...@googlemail.com> wrote:
> > Biggest market issues for me are :
> > - copy protection doesn't work - apps get hacked and redistributed
> > within 24 hours
> > - users backup apps to sdcard, refund and reinstall = no payment to
> > dev
> > - payments fail on international orders
> > - most countries still excluded from paid apps
> > The 4 issues above mean that for every sale that a dev is only
> > achieving a low percentage of sales he or she has earned - maybe as
> > low as 30% although this is obviously just a guess.
> > Google please fix so that app devs are motivated to make better apps
> > rather than have their work stolen or simply unavailable to users who
> > want to buy (which only fuels the illegal market further).
> > And yes I have listed on alternative markets - but the experience so
> > far is that most users give up after attempting purchase on primary
> > market.- Hide quoted text -
Regarding stats its very hard to get accurate numbers.
You are right in that the app retention stat on the dev console can
help show loss of sales through point 2 below.
On point 3, I can see on my order book that this results in the loss
of 15 - 20% of orders as I am in the UK - I believe this figure is
closer to 5% for US publishers.
Loss of sales from points 1 and 4 is almost impossible to calculate -
thats why I guessed a total loss of 70% on sales from all these
factors combined ...
1. copy protection doesn't work - apps get hacked and redistributed
within 24 hours
2. users backup apps to sdcard, refund and reinstall = no payment to
dev
3. payments fail on international orders
4. most countries still excluded from paid apps
And sadly if the hackers want your new features enough, e.g. a major
update, they will get it out to their minions within 24 hours.
I agree that it is a little disappointing that there is no better protection
scheme, and that the losses hurt.
A quick story: our app, PhoneMyPC, a PC remoting app is a combination
application and hosted service. The phone and PC use our servers to
cooperatively get connected for each remote control session. This makes
PhoneMyPC ideal for people inside corporate firewalls, or who just don't
want to bother configuring for RDP or VNC.
We are nearing the end of a [protracted] Beta program. In the beginning, we
were hosting on port 443. Several weeks ago we switched to a different port
(temporarily), and kept both services running while users downloaded the new
release.
Most people moved to the new server within a week, but a large body (half of
all connections using our service) never moved at all. After more than two
weeks, we discontinued service on the old port, and there has not yet been a
single support contact as a result.
We made the decision to disconnect the old service even though it was still
being well used because we discovered our app being sold illegally on one of
the websites talked about in this group.
So, our "retention for pay" rate is also about 70%, yet we believe as many
as half of the people using our application (or at least possessing it) have
acquired it outside of the Android Market (and hence are not automatically
getting updates).
For our purposes, Google could trivially enable us to protect our resources
by adding any phone identifier into the Google Checkout records, such as
phone number or IMEI, so that we could tie phones running our app back to
thei purchase records.
Scott,
SoftwareForMe.com
On Thu, Oct 29, 2009 at 8:12 AM, admin.androidsl...@googlemail.com <
> Regarding stats its very hard to get accurate numbers.
> You are right in that the app retention stat on the dev console can
> help show loss of sales through point 2 below.
> On point 3, I can see on my order book that this results in the loss
> of 15 - 20% of orders as I am in the UK - I believe this figure is
> closer to 5% for US publishers.
> Loss of sales from points 1 and 4 is almost impossible to calculate -
> thats why I guessed a total loss of 70% on sales from all these
> factors combined ...
> 1. copy protection doesn't work - apps get hacked and redistributed
> within 24 hours
> 2. users backup apps to sdcard, refund and reinstall = no payment to
> dev
> 3. payments fail on international orders
> 4. most countries still excluded from paid apps
> And sadly if the hackers want your new features enough, e.g. a major
> update, they will get it out to their minions within 24 hours.
I wouldn't use IMEI or phone-number.
App purchases are linked to a google account. If a user switches to a
new phone, they'd need a new activation and this can mean support
headaches for the app developer.
Google should give us a good way to identify the user as he/she is
tied to his/her google-account that was active when the app was
downloaded from the Android Market. It should not be the account-name
itself (privacy) but some proper hash of it that remains unique.
On Oct 29, 4:56 pm, "SoftwareForMe.com SoftwareForMe.com"
<softwareforme....@gmail.com> wrote:
> I agree that it is a little disappointing that there is no better protection
> scheme, and that the losses hurt.
> A quick story: our app, PhoneMyPC, a PC remoting app is a combination
> application and hosted service. The phone and PC use our servers to
> cooperatively get connected for each remote control session. This makes
> PhoneMyPC ideal for people inside corporate firewalls, or who just don't
> want to bother configuring for RDP or VNC.
> We are nearing the end of a [protracted] Beta program. In the beginning, we
> were hosting on port 443. Several weeks ago we switched to a different port
> (temporarily), and kept both services running while users downloaded the new
> release.
> Most people moved to the new server within a week, but a large body (half of
> all connections using our service) never moved at all. After more than two
> weeks, we discontinued service on the old port, and there has not yet been a
> single support contact as a result.
> We made the decision to disconnect the old service even though it was still
> being well used because we discovered our app being sold illegally on one of
> the websites talked about in this group.
> So, our "retention for pay" rate is also about 70%, yet we believe as many
> as half of the people using our application (or at least possessing it) have
> acquired it outside of the Android Market (and hence are not automatically
> getting updates).
> For our purposes, Google could trivially enable us to protect our resources
> by adding any phone identifier into the Google Checkout records, such as
> phone number or IMEI, so that we could tie phones running our app back to
> thei purchase records.
> Scott,
> SoftwareForMe.com
> On Thu, Oct 29, 2009 at 8:12 AM, admin.androidsl...@googlemail.com <
> > Regarding stats its very hard to get accurate numbers.
> > You are right in that the app retention stat on the dev console can
> > help show loss of sales through point 2 below.
> > On point 3, I can see on my order book that this results in the loss
> > of 15 - 20% of orders as I am in the UK - I believe this figure is
> > closer to 5% for US publishers.
> > Loss of sales from points 1 and 4 is almost impossible to calculate -
> > thats why I guessed a total loss of 70% on sales from all these
> > factors combined ...
> > 1. copy protection doesn't work - apps get hacked and redistributed
> > within 24 hours
> > 2. users backup apps to sdcard, refund and reinstall = no payment to
> > dev
> > 3. payments fail on international orders
> > 4. most countries still excluded from paid apps
> > And sadly if the hackers want your new features enough, e.g. a major
> > update, they will get it out to their minions within 24 hours.
> --
> Warm regards,
> The PhoneMyPC Team- Hide quoted text -
> I wouldn't use IMEI or phone-number.
> App purchases are linked to a google account. If a user switches to a
> new phone, they'd need a new activation and this can mean support
> headaches for the app developer.
> Google should give us a good way to identify the user as he/she is
> tied to his/her google-account that was active when the app was
> downloaded from the Android Market. It should not be the account-name
> itself (privacy) but some proper hash of it that remains unique.
> On Oct 29, 4:56 pm, "SoftwareForMe.com SoftwareForMe.com"
> <softwareforme....@gmail.com> wrote:
> > I agree that it is a little disappointing that there is no better
> protection
> > scheme, and that the losses hurt.
> > A quick story: our app, PhoneMyPC, a PC remoting app is a combination
> > application and hosted service. The phone and PC use our servers to
> > cooperatively get connected for each remote control session. This makes
> > PhoneMyPC ideal for people inside corporate firewalls, or who just don't
> > want to bother configuring for RDP or VNC.
> > We are nearing the end of a [protracted] Beta program. In the beginning,
> we
> > were hosting on port 443. Several weeks ago we switched to a different
> port
> > (temporarily), and kept both services running while users downloaded the
> new
> > release.
> > Most people moved to the new server within a week, but a large body (half
> of
> > all connections using our service) never moved at all. After more than
> two
> > weeks, we discontinued service on the old port, and there has not yet
> been a
> > single support contact as a result.
> > We made the decision to disconnect the old service even though it was
> still
> > being well used because we discovered our app being sold illegally on one
> of
> > the websites talked about in this group.
> > So, our "retention for pay" rate is also about 70%, yet we believe as
> many
> > as half of the people using our application (or at least possessing it)
> have
> > acquired it outside of the Android Market (and hence are not
> automatically
> > getting updates).
> > For our purposes, Google could trivially enable us to protect our
> resources
> > by adding any phone identifier into the Google Checkout records, such as
> > phone number or IMEI, so that we could tie phones running our app back to
> > thei purchase records.
> > Scott,
> > SoftwareForMe.com
> > On Thu, Oct 29, 2009 at 8:12 AM, admin.androidsl...@googlemail.com <
> > > Regarding stats its very hard to get accurate numbers.
> > > You are right in that the app retention stat on the dev console can
> > > help show loss of sales through point 2 below.
> > > On point 3, I can see on my order book that this results in the loss
> > > of 15 - 20% of orders as I am in the UK - I believe this figure is
> > > closer to 5% for US publishers.
> > > Loss of sales from points 1 and 4 is almost impossible to calculate -
> > > thats why I guessed a total loss of 70% on sales from all these
> > > factors combined ...
> > > 1. copy protection doesn't work - apps get hacked and redistributed
> > > within 24 hours
> > > 2. users backup apps to sdcard, refund and reinstall = no payment to
> > > dev
> > > 3. payments fail on international orders
> > > 4. most countries still excluded from paid apps
> > > And sadly if the hackers want your new features enough, e.g. a major
> > > update, they will get it out to their minions within 24 hours.
> > --
> > Warm regards,
> > The PhoneMyPC Team- Hide quoted text -
All sounds good - I hope someone from Google is taking note.
Also please remember that cancelled transactions within 24 hours would
need to fail any validation checks in order for this to work.
Google must look at fixing payment issues too (download stalled,
invalid currency, no support for many countries, etc.) - I often hear
users complaining that when they can't buy legitimately, they just
download an illegal copy - best not to give them that excuse ...
On Oct 29, 9:31 pm, "SoftwareForMe.com SoftwareForMe.com"
> I was thinking Phone# is better than IMEI, because 99% of people take their
> phone numbers with them.
> But, I thought if someone got a new number, I could query for sufficient
> details to "re-enabled" from the old checkout record.
> Actually, it seems the best would be simply embedding the Google Checkout
> transaction ID in the APK somehow, or otherwise making it available.
> Scott,
> SoftwareForMe.com
> On Thu, Oct 29, 2009 at 2:04 PM, Streets Of Boston
> <flyingdutc...@gmail.com>wrote:
> > I wouldn't use IMEI or phone-number.
> > App purchases are linked to a google account. If a user switches to a
> > new phone, they'd need a new activation and this can mean support
> > headaches for the app developer.
> > Google should give us a good way to identify the user as he/she is
> > tied to his/her google-account that was active when the app was
> > downloaded from the Android Market. It should not be the account-name
> > itself (privacy) but some proper hash of it that remains unique.
> > On Oct 29, 4:56 pm, "SoftwareForMe.com SoftwareForMe.com"
> > <softwareforme....@gmail.com> wrote:
> > > I agree that it is a little disappointing that there is no better
> > protection
> > > scheme, and that the losses hurt.
> > > A quick story: our app, PhoneMyPC, a PC remoting app is a combination
> > > application and hosted service. The phone and PC use our servers to
> > > cooperatively get connected for each remote control session. This makes
> > > PhoneMyPC ideal for people inside corporate firewalls, or who just don't
> > > want to bother configuring for RDP or VNC.
> > > We are nearing the end of a [protracted] Beta program. In the beginning,
> > we
> > > were hosting on port 443. Several weeks ago we switched to a different
> > port
> > > (temporarily), and kept both services running while users downloaded the
> > new
> > > release.
> > > Most people moved to the new server within a week, but a large body (half
> > of
> > > all connections using our service) never moved at all. After more than
> > two
> > > weeks, we discontinued service on the old port, and there has not yet
> > been a
> > > single support contact as a result.
> > > We made the decision to disconnect the old service even though it was
> > still
> > > being well used because we discovered our app being sold illegally on one
> > of
> > > the websites talked about in this group.
> > > So, our "retention for pay" rate is also about 70%, yet we believe as
> > many
> > > as half of the people using our application (or at least possessing it)
> > have
> > > acquired it outside of the Android Market (and hence are not
> > automatically
> > > getting updates).
> > > For our purposes, Google could trivially enable us to protect our
> > resources
> > > by adding any phone identifier into the Google Checkout records, such as
> > > phone number or IMEI, so that we could tie phones running our app back to
> > > thei purchase records.
> > > Scott,
> > > SoftwareForMe.com
> > > On Thu, Oct 29, 2009 at 8:12 AM, admin.androidsl...@googlemail.com <
> > > > Regarding stats its very hard to get accurate numbers.
> > > > You are right in that the app retention stat on the dev console can
> > > > help show loss of sales through point 2 below.
> > > > On point 3, I can see on my order book that this results in the loss
> > > > of 15 - 20% of orders as I am in the UK - I believe this figure is
> > > > closer to 5% for US publishers.
> > > > Loss of sales from points 1 and 4 is almost impossible to calculate -
> > > > thats why I guessed a total loss of 70% on sales from all these
> > > > factors combined ...
> > > > 1. copy protection doesn't work - apps get hacked and redistributed
> > > > within 24 hours
> > > > 2. users backup apps to sdcard, refund and reinstall = no payment to
> > > > dev
> > > > 3. payments fail on international orders
> > > > 4. most countries still excluded from paid apps
> > > > And sadly if the hackers want your new features enough, e.g. a major
> > > > update, they will get it out to their minions within 24 hours.
> > > --
> > > Warm regards,
> > > The PhoneMyPC Team- Hide quoted text -
On Thu, Oct 29, 2009 at 9:31 PM, SoftwareForMe.com SoftwareForMe.com
<softwareforme....@gmail.com> wrote: > I agree. > I was thinking Phone# is better than IMEI, because 99% of people take their > phone numbers with them. > But, I thought if someone got a new number, I could query for sufficient > details to "re-enabled" from the old checkout record. > Actually, it seems the best would be simply embedding the Google Checkout > transaction ID in the APK somehow, or otherwise making it available. > Scott, > SoftwareForMe.com
Woh there. Drop that percentage by a good amount SoftwareForMe.com...
Just like you, I take my number with me. But the majority of people I know don't. I'm not saying 99% of people DON'T keep their numbers - just suggesting that my friends, family and colleagues can't all squeeze into that remaining 1% :)
I still don't see the appeal for DRM, there are plenty of other options - licence keys, periodical payments, and pay-for upgrades... All of which avoid having to double your support efforts just because people like to change their phones and email addresses.
I consider the Android Market as a "app shop"; it is a place to get your software noticed and shipped. Not as a means to an end for developers when considering piracy protection, distribution methods, and payment options.
Having said all that, improvements to the market will always be welcomed. I just think the issues listed against the current AM should not be a big deal to any serious developer who doesn't whittle their time away making the next fart soundboard app for £5. Yes, the Android Market is insufficient in certain areas, but anyone serious about selling mobile apps will also consider options outside of the Android Market.
> All sounds good - I hope someone from Google is taking note.
> Also please remember that cancelled transactions within 24 hours would > need to fail any validation checks in order for this to work.
> Google must look at fixing payment issues too (download stalled, > invalid currency, no support for many countries, etc.) - I often hear > users complaining that when they can't buy legitimately, they just > download an illegal copy - best not to give them that excuse ...
You have a point here. I am one of the users that can't buy from the Android Market. If the app cannot be purchased from something other than Google Checkout, then I seek alternative apps. Many others I know, however, would rather just jump to the nearest torrent site and get the app illegitimately.
The solution is to offer other ways to buy the app, and advertise them. Alternative markets are one way, and direct selling is another. Hopefully the Android Market will improve it's International payment process, but even then it is not a good idea to rely on a single distribution method.
I also agree. It wont stop piracy but it will no longer be as simple as copy and paste. Now if somebody wants to pirate your app they will need to spend hours.
On Oct 29, 2009, at 5:31 PM, "SoftwareForMe.com SoftwareForMe.com" <softwareforme....@gmail.com> wrote:
I agree.
I was thinking Phone# is better than IMEI, because 99% of people take their phone numbers with them.
But, I thought if someone got a new number, I could query for sufficient details to "re-enabled" from the old checkout record.
Actually, it seems the best would be simply embedding the Google Checkout transaction ID in the APK somehow, or otherwise making it available.
Scott,
SoftwareForMe.com
On Thu, Oct 29, 2009 at 2:04 PM, Streets Of Boston <flyingdutc...@gmail.com> wrote:
I wouldn't use IMEI or phone-number.
App purchases are linked to a google account. If a user switches to a
new phone, they'd need a new activation and this can mean support
headaches for the app developer.
Google should give us a good way to identify the user as he/she is
tied to his/her google-account that was active when the app was
downloaded from the Android Market. It should not be the account-name
itself (privacy) but some proper hash of it that remains unique.
On Oct 29, 4:56 pm, "SoftwareForMe.com SoftwareForMe.com"
<softwareforme....@gmail.com> wrote:
> I agree that it is a little disappointing that there is no better protection
> scheme, and that the losses hurt.
> A quick story: our app, PhoneMyPC, a PC remoting app is a combination
> application and hosted service. The phone and PC use our servers to
> cooperatively get connected for each remote control session. This makes
> PhoneMyPC ideal for people inside corporate firewalls, or who just don't
> want to bother configuring for RDP or VNC.
> We are nearing the end of a [protracted] Beta program. In the beginning, we
> were hosting on port 443. Several weeks ago we switched to a different port
> (temporarily), and kept both services running while users downloaded the new
> release.
> Most people moved to the new server within a week, but a large body (half of
> all connections using our service) never moved at all. After more than two
> weeks, we discontinued service on the old port, and there has not yet been a
> single support contact as a result.
> We made the decision to disconnect the old service even though it was still
> being well used because we discovered our app being sold illegally on one of
> the websites talked about in this group.
> So, our "retention for pay" rate is also about 70%, yet we believe as many
> as half of the people using our application (or at least possessing it) have
> acquired it outside of the Android Market (and hence are not automatically
> getting updates).
> For our purposes, Google could trivially enable us to protect our resources
> by adding any phone identifier into the Google Checkout records, such as
> phone number or IMEI, so that we could tie phones running our app back to
> thei purchase records.
> Scott,
> SoftwareForMe.com
> On Thu, Oct 29, 2009 at 8:12 AM, admin.androidsl...@googlemail.com <
> > Regarding stats its very hard to get accurate numbers.
> > You are right in that the app retention stat on the dev console can
> > help show loss of sales through point 2 below.
> > On point 3, I can see on my order book that this results in the loss
> > of 15 - 20% of orders as I am in the UK - I believe this figure is
> > closer to 5% for US publishers.
> > Loss of sales from points 1 and 4 is almost impossible to calculate -
> > thats why I guessed a total loss of 70% on sales from all these
> > factors combined ...
> > 1. copy protection doesn't work - apps get hacked and redistributed
> > within 24 hours
> > 2. users backup apps to sdcard, refund and reinstall = no payment to
> > dev
> > 3. payments fail on international orders
> > 4. most countries still excluded from paid apps
> > And sadly if the hackers want your new features enough, e.g. a major
> > update, they will get it out to their minions within 24 hours.
> --
> Warm regards,
> The PhoneMyPC Team- Hide quoted text -
