Pearson API is pretty nice for different innovative mobile apps.
But there is the issue with paid apps and in-app purchase business models and Pearson API business model. When the user pay for the application or buy something inside he would like to own and use it as much as he want, similar as he does with paper Pearson products(buying a paper dictionary for example). According to Pearson API terms and condition the data on the mobile phone of particular user could be stored up to 7 days. That means that paid feature or app should dissapear from user phone in 7 days or app owners should pay forever for Pearson API while user uses it.
Seems like paid apps or in-app purchase models for apps based on Pearson content will be unprofitable. Also looks like it is impossible to use app with Pearson content offline(or just 7 days).
However, there are no any issues with ads business model(free apps with ads inside) and subscribtion model.
But the problem is that many innovative apps require offline usage and paid/in-app purchase business model.
Could you please help if exist any solution around it?
25/04/2012 12:33:59
Hi Dan,
Yes, It would be great to have a teleconference where we could show you the app and discuss what is possible.
Please let me know what date/time best works for you.
My email - nazar.bilous@lemberg.co.uk.
Naz
19/04/2012 15:52:40
Interesting thoughts, we are keen to look at what we can do to facilitate some of these things and client libraries would certainly make things easier for app developers.
I would love to see us have a number of models available and choose the one which fits well for us and devs. At the same time this might be confusing and so it would be great to have a small number of options which work for 80-90% of developers. I'm not sure what we would need to do in order to support this, or even if technically/legally we could...
Would you like to have a teleconference about your idea, perhaps you could show it and we could talk about your concerns ?
Dan
13/04/2012 14:35:40
Hi Dan,
I've got some ideas how to implement it to life. The problem is that Apple store and Google play tools and business models are meant for
apps developers in one person/organisation, who are the owners of whole app. Pearson started a good movement with allowing anybody build apps around their content. In this situation we have basically two stakeholders around the app: content-owner and app-developer. And we need to split income and risks between them fairly. In the same time the user of the application mostly pay one time for the app/feature and would like to use it as much as he would like. I guess this principle should be across all stakeholders, which means in our case that content-owner and app-developer will receive money one time from one user.
To implement this in life you should define the user on your side. To make it without any additional pain of user login I see the way of developing iOS and Android libraries for access to Pearson content. This will allow you to define users using device id or other techniques.
I think that for mobile apps terms should be definitely other. Pay per request scheme looks obsolete and is stopper for mobile apps (it works for web projects, because monetization is based on traffic/requests). I also believe that sell content on per mobile user base will be revolutionary and all content owners around the world will follow this approach.
11/04/2012 12:58:40
Hi Dan,
Many thanks for your answer. I see your point. I guess that allowing a longer device cache doesn't solve the issue. Would be great somehow to identify iOS/Android user on your side and sell content on per mobile user base.
At the moment I have no ideas, how to split risks and expenses between content owner and developer fairly.
Regarding application, we would like to use Longman dictionary API(words, meaning and photos) as a content for educational puzzle/vocabulary game. The prototype of Android app is already developed.
05/04/2012 11:53:51
Hi,
Thanks for the reply and clarification of your concerns.I think this is an interesting challenge and great topic for discussion.
Think there are a couple more matters to consider in addition to the points and suggestion you raise which might help explain our current thoughts and what we're considering doing in the future. These are:
"Cache size and dataset size" and "Identification of end users".
The Longman Dictionary takes is based on about 100MB of XML plus 4.6 GB of multimedia. I'm not suggesting that all of this would end up being accessed many users, but it does (I hope) show that any app that locally caches will probably have to make a decision about how it manages the cache and accept that it might be necessary to download the information more than once. Also, if a user's device breaks and gets replaced or upgraded to a newer model then again a piece of content would need to be downloaded. Lastly if a user owns multiple devices then the same content might need to be downloaded to 2 or more devices... so my feeling is that a download once and keep forever starts to look tricky.
We don't currently identify end users. This means we don't know if a request is from the same user on the same device, a different device or a different user. As such we fall back into the simple web-hit or page request way of counting downloads, unless we can tell it is the same person we have to assume it isn't.
We could change. It will affect what you as a developer needs to do. For example we could require an authenticated user token such as OAuth2. This would allow us to see that the request is coming from the same person for the same content. In turn it would require developers ask users to login and this may not be acceptable to all developers and would also affect the current prices.
Maybe just allowing a longer device cache would be sufficient, although none of the developers I've spoken to have implemented any API caching. It would probably mean developers would need to find or write a cache manager, but I'm guessing this isn't an issue for you. Do you already have an app developed? Which APIs does it use ?
04/04/2012 12:30:05
Basically this is very important for mobile apps.
Idea for the solution:
- split terms of use for End User commercial applications and commercial applications
04/04/2012 12:26:03
Hi Dan,
Many thanks for your feedback.
If we are talking about the example you described, the one user will use the application for a long time and generate API calls every day and months(and that is true for valuable apps). That means that owner of the application should pay for the API calls every months for the same users which do not generate for him new revenue if we are talking about paid app or/and in-app purchase model (because user paid one time for the app or feature based on content and want to use it as long as he like). Just in subscribtion or ads business model owner of the app could receive revenue from the same customer and cover expenses which generate this customer.
From my point of view if the app sell the feature/app based on Pearson content to the end users, user should have the way to use it as long as he would like and all stakeholders should pay for this one time(user to app owner, app owner to Pearson). Do you have ideas how to make such business model possible?
21/03/2012 13:28:27
Hi Bilousnazar,
There may be some confusions here. Only the content that was retrieved needs to go after 7 days (although the terms are different for different APIs), the app can stay. Maybe I have misinterpreted your comment.
If we take the Kitchen Manager API as an example, it allows up to 250K calls per month for £30.
If a user does a 2 or 3 searches and browses a couple of recipes, it may result in 10 calls to the API before a user decides on a recipe to use. In an extreme case, the user could repeat this everyday so they might use 300 or so of the monthly quota, which should allow your app to support over 800 extremely high use users for £30 per month.
Early feedback we had from developers was this was preferable then charging a higher fee per call and allowing longer caching, although it sounds like this is your preference ?
I would be interested if you could share your thoughts commercial models, we'd really appreciate this feedback.