We are putting together an improved version of the current embedded AudioJungle player in HTML5 which also will work on mobile devices. There is an alpha version of this player now available for trying out. Please visit the UI generator, customise the player with different configuration and give it a try. Just remember that this version is not suitable for production environment.
Similar to the current flash player the new player also lets you customise the color scheme, playlist source and size. You should be able to copy the code from the UI generator and paste it in your own html pages to embed the new player.
Good luck and let us know what you think.
They include minor enhancements. In particular we have introduced caching. Since themes aren’t updated on minutely basis, both the plugin and the library cache their results for a short period of time to avoid contacting the server every time they are used. This should make the process feel faster to use.
Please let us know if you find any issues.
Just to be clear, you don’t HAVE to use this, do you?
I completely agree with the majority of concerns expressed by other authors, especially by Parallelus and sevenspark.
I wish you guys re-consider your decision to make it mandatory, at least not for a while. If I had a choice I would not implement this right now. We want to make sure that the benefits clearly outnumber the potential issues.
A question, if you would put pageviews, referrals and searches in one page would that slow down the loading time? The loading times are still bad but it gets worse by having to check three different pages for each item.
UX improvements are in the pipeline
Please implement some kind of conversion tracking so we can actually put the analytics tool to some use.
We looked at the conversions report, but there wasn’t a straight forward way to extract conversions based on different author or item. It will require some dev work. As I have previously mentioned, I do this work outside of the core dev team and have no power to change things on their side.
I’m excited to say the Envato Analytics (EA) website has had its first update since Vahid’s post. Here is what’s changed:
- Bounce rate and exit rate are now shown
- Reports now show when they were fetched (from now onwards)
- There are links to individual reports on the items page
- And some small UI changes
We also spent time on making the site faster and even moved the entire server to the AWS infrastructure. Unfortunately the Google Analytics API is simply too slow. Hence we have tried to come up with smarter ways to make EA feel faster; like making the UI give better feedback while it’s fetching a report.
Since this update we are also better able to track our usage of the Google Analytics API . With this information in hand we hope to add more of your suggestions to EA. In the meantime please let us know if this update has broken things for you.
@halogenic, thanks for a comprehensive report. We have identified the problem and there will be an update available shortly.
This plugin and PHP library are a work in progress, so we are really glad to see people take them for a spin and report issues. Derek and I will look at these problems but it would really help us if with your reports the following points can also be included:
- which theme on the marketplace did you have trouble with?
- did you receive errors while testing the Plugin or the Library?
- if using the library, please describe how you were doing it so we can replicate your scenario
- if using the plugin, were you installing a new theme or upgrading an installed theme?
- and obviously what errors you got
Thanks for the feedback!
Some of you may already know that I maintain the Envato Analytics (EA) website for Envato, but you may not know that I work for Envato as an external contractor. The upside is that my contribution does not impact the development projects that Envato itself is working on and we are all eagerly waiting for. The downside is that I have to work with resources that are generally available.
I have gone through your suggestions and grouped them into those which require changes to Envato API , i.e. exposing extra data and those which I can address without Envato developer involvement. Obviously, my immediate plan is to focus on the data that is generally available, specifically via Google Analytics. Then over time, as the Envato API matures, to deliver some of your other requests. I hope that works for all of you.
This nicely brings me to my next point re Google Analytics. When EA was first started in 2010, Google Analytics API limited client applications to 10,000 API calls per day. As you know Envato has tens of thousands of authors and well over 1M items across all marketplaces. While not all authors check every one of their items on the daily basis, it’s easy to imagine how quickly the APIs could be used up! So currently we ration the API calls. Fortunately, Google recently increased the API quota from 10,000 to 50,000 API calls per day per project, which puts us in a position to tackle some of the suggested features from this thread.
The next thing is the issue of speed, which has been raised a number of times. I am going to experiment a little bit to see if anything can be done to improve response times. I do not want to raise expectations for significant improvements as there is one thing that we can’t change and that is the speed with which Google Analytics responds to our queries. Accessing the data through the Google APIs is the slowest component of our application. How slow you might ask? Let’s just say because Envato accumulates such large amounts of traffic data sometimes it takes a long time to view a report even on Google’s own analytics website. This is really unfortunate and naturally forces us to favour faster reporting options over slower ones. For example, there are a number of requests to merge the three views provided onto one page. Well that is very easy to do, but currently each view takes an API call, so imagine taking 3 times longer so that it can all be on one page! Furthermore, merging three views into one view consumes 3 API calls, when the author may not be interested in all of the views.
Having said all of the above I am working through your suggestions and over the next few months will be releasing incremental improvements.
I want to thank everyone for adding their views to this discussion, which has been really insightful, and if other thoughts come to mind, please post away!