Showing posts with label enhancing. Show all posts
Showing posts with label enhancing. Show all posts
Friday, September 29, 2017
Google Analytics is Enhancing Support for AMP
Google Analytics is Enhancing Support for AMP
Over the past year, developers have adopted the Accelerated Mobile Pages (AMP) technology to build faster-loading pages for all types of sites, ranging from news to recipes to e-commerce. Billions of AMP pages have been published to date and Google Analytics continues its commitment to supporting our customers who have adopted AMP.
However, we have heard feedback from Google Analytics customers around challenges in understanding the full customer journey due to site visitors being identified inconsistently across AMP and non-AMP pages. So were announcing today that we are rolling out an enhancement that will give you an even more accurate understanding of how people are engaging with your business across AMP and non-AMP pages of your website.
How will this work?
This change brings consistency to users across AMP and non-AMP pages served from your domain. It will have the effect of improving user analysis going forward by unifying your users across the two page formats. It does not affect AMP pages served from the Google AMP Cache or any other AMP cache.
When will this happen?
We expect these improvements to be complete, across all Google Analytics accounts, over the next few weeks.
Are there any other implications of this change?
As we unify your AMP and non-AMP users when they visit your site in the future, you may see changes in your user and session counts, including changes to related metrics. User and session counts will go down over time as we recognize that two formerly distinct IDs are in fact the same user; however, at the time this change commences, the metric New Users may rise temporarily as IDs are reset.
In addition, metrics like time on site, page views per session, and bounce rate will rise consistent with sessions with AMP and non-AMP pageviews no longer being treated as multiple sessions. This is a one-time effect that will continue until all your users who have viewed AMP pages in the past are unified (this can take a short or long period of time depending on how quickly your users return to your site/app).
Is there anything I need to do to get this update?
There is no action required on your part, these changes will be automatically rolled out.
Will there be changes to unify users who view my pages both on my domain and in other contexts?
Some AMP pages are not visited directly on the domain where the content is originally hosted but instead via AMP caches or in platform experiences. However we decided to focus on fixing the publisher domain case first as this was the fastest way we could add value for our clients.
We are committed to ensuring the best quality data for user journey analysis across AMP and non-AMP pages alike and this change makes that easy for AMP pages served on your domain. We hope you enjoy these improvements - and as always, happy analyzing!
However, we have heard feedback from Google Analytics customers around challenges in understanding the full customer journey due to site visitors being identified inconsistently across AMP and non-AMP pages. So were announcing today that we are rolling out an enhancement that will give you an even more accurate understanding of how people are engaging with your business across AMP and non-AMP pages of your website.
How will this work?
This change brings consistency to users across AMP and non-AMP pages served from your domain. It will have the effect of improving user analysis going forward by unifying your users across the two page formats. It does not affect AMP pages served from the Google AMP Cache or any other AMP cache.
When will this happen?
We expect these improvements to be complete, across all Google Analytics accounts, over the next few weeks.
Are there any other implications of this change?
As we unify your AMP and non-AMP users when they visit your site in the future, you may see changes in your user and session counts, including changes to related metrics. User and session counts will go down over time as we recognize that two formerly distinct IDs are in fact the same user; however, at the time this change commences, the metric New Users may rise temporarily as IDs are reset.
In addition, metrics like time on site, page views per session, and bounce rate will rise consistent with sessions with AMP and non-AMP pageviews no longer being treated as multiple sessions. This is a one-time effect that will continue until all your users who have viewed AMP pages in the past are unified (this can take a short or long period of time depending on how quickly your users return to your site/app).
Is there anything I need to do to get this update?
There is no action required on your part, these changes will be automatically rolled out.
Will there be changes to unify users who view my pages both on my domain and in other contexts?
Some AMP pages are not visited directly on the domain where the content is originally hosted but instead via AMP caches or in platform experiences. However we decided to focus on fixing the publisher domain case first as this was the fastest way we could add value for our clients.
We are committed to ensuring the best quality data for user journey analysis across AMP and non-AMP pages alike and this change makes that easy for AMP pages served on your domain. We hope you enjoy these improvements - and as always, happy analyzing!
download file now
Thursday, September 7, 2017
Thoughts about enhancing application permission control
Thoughts about enhancing application permission control
It occurred to me and (a lot of other people, as will be shown) that with Android applications, it may be useful to extend permission management for installed applications to enable logging/auditing or finer grained control. I remembered seeing some application which provided some of that functionality, but was unsure of exact details. Since this area of Android just might be suitable for me to try some enhancements, it seemed appropriate to explore the following points:
- What existing solutions or ideas are available for extending Androids permission system? What are their principles of operation?
- How does the Android system enforce Application permissions, and where is the relevant component in its source code?
- What can malware do with regard to application permissions
The existing application / modification and how these work
It turns out that there have been a couple of similar attempts to enhance permissions on android, below listed in no particular order:- PDroid, made by xda-developers.com community members. Consists of Android source patches and controlling user application. The patches modify system services which provide data for telephony, location and similar API calls (TelephonyManager, LocationManager, ...), creating wrappers for these components. The wrapper components check for application-set rules for handling permissions or logging. Patches (source) available, but application is closed-source.
- Cyanogenmod had modifications in the system components and application (UI) for revoking specific permissions to applications. Applications behaved as though the permission was not requested at install time by the application, and may crash. Theese extensions are no longer present in newer versions (since they caused applications to misbehave, become incompatible, etc.)
- papers Android Permissions Demystified, APEX, and a few other referenced therein. These enhancements have different approaches, goals or implementations which are described well in the respective papers, but do not have source code available.
- a few proprietary or commercial tools such as LBE Privacy Guard
Identifying components in Android system which grant permissions when application does an action which requires permission
Androids developer documentation on permissions outlines general situations when permissions are necessary: API calls for activity or services, accepting data from other applications (receiving broadcasts) or providing it (content providers).The documentation also shows actual permissions required for calls to certain parts of the API. A somewhat useful representation of this is the permission map which was created from the API as part of the Android Permissions Demystified project mentioned above.
The aforementioned papers Android Permissions Demystified and APEX provide a description of how the permissions are checked, around page 3, or pages 5, 6, section 4, for the two papers respectively. A summary of this follows. When an application calls an API method, the call is propagated through Androids inter-process communication to the system service which can service the API request (example: LocationManagerService provides location). The system component classes must check for permissions regarding to the action, using methods such as checkPermission, enforcePermission from Context (be it Activity, Service or other context). The actual decision is done in the PackageManagerService which grants or denies permissions depending on those requested at install time.
How simple malware might be done, relating to permission management
Some permissions in the Android system are broad, while others are fine-grained. An example of broad permission is the INTERNET permission, which allows any socket access. Malicious applications might claim to be using the permissions for some legitimate and benign task, while in reality that permission allows it to do additional malicious functionality.download file now
Monday, September 4, 2017
Google Analytics is enhancing support for AMP on cache
Google Analytics is enhancing support for AMP on cache
With users getting more and more impatient with slow mobile pages, developers are increasingly investing in a faster web experience with solutions like Accelerated Mobile Pages (AMP). Billions of AMP pages have been published by all kinds of mobile sites � from news to recipes to e-commerce. With so much AMP content being published every week, Google Analytics continues to evolve to support those of our customers who have adopted AMP.
Today we are excited to be the first supporting vendor to announce a new service, Google�s AMP Client ID API, that will enable the same benefits for AMP pages displayed via Google surfaces. In May of this year we launched a solution to help you better understand your customers� journeys across AMP and non-AMP experiences that were hosted on your own domain. Google�s AMP Client ID API will enable the same benefits for AMP pages displayed by Google such as in Google Search.
To get started you�ll have to opt-in to this solution via a code change. The small code change is required on both your AMP and non-AMP websites to enable this as well as an acknowledgement of the new Google Analytics terms for usage of this API.
Opt into this new feature today to get deeper insight into how users are interacting with your AMP pages.
Happy Analyzing!
Today we are excited to be the first supporting vendor to announce a new service, Google�s AMP Client ID API, that will enable the same benefits for AMP pages displayed via Google surfaces. In May of this year we launched a solution to help you better understand your customers� journeys across AMP and non-AMP experiences that were hosted on your own domain. Google�s AMP Client ID API will enable the same benefits for AMP pages displayed by Google such as in Google Search.
How will this work?
This solution works by allowing your web pages, which may be partially served on Google platforms and partially on your domain, to communicate with each other. This communication happens via a newly introduced Google API and with Google Analytics such that it can understand if a user on your non-AMP pages had ever visited an AMP page displayed by Google. When true, Google Analytics can help you understand user behavior across these two page types as a single cohesive experience.To get started you�ll have to opt-in to this solution via a code change. The small code change is required on both your AMP and non-AMP websites to enable this as well as an acknowledgement of the new Google Analytics terms for usage of this API.
When will this happen?
The ability to opt-in to this solution is available today and you can find code instructions and new terms here. Please review the documentation and opt-in when you are ready.Are there any other implications of this change?
Once you opt-in to this solution you will notice changes to some of your metrics. Your user and session metrics will drop down to more accurate counts as formerly distinct users are recognised as the same person, as well as related metrics that will also become more accurate (such as Time on Site and Bounce Rate). And New Users may rise temporarily. This is a function of the product more accurately counting your users. Its a one-time effect that will continue until all your users who have viewed AMP pages in the past return to your site (this can take a short or long period of time depending on how quickly your users return to your site/app). To get more detail about what may change, please read our help center article.Opt into this new feature today to get deeper insight into how users are interacting with your AMP pages.
Happy Analyzing!
download file now
Subscribe to:
Posts (Atom)