SAP NetWeaver Portal Analytics An Overview and Comparison of SAP Portal Analytics Tools

Transcription

2 Contents 1 Portal Analytics Overview Data collection methods Overview of SAP Portal Analytics Products SAP portal activity report (PAR) SAP activity data collector (ADC) (Adobe SiteCatalyst) by Sweetlets SAP Portal Analytics Product Comparisons Proxies and caches Page-loading issues Export features Cookies, JavaScript and images Real-time reporting and real-time data Setup and implementation costs Data storage time frame Reprocessing analytics data User and group activity data Intranet optimization User privacy Corporate data security Data and reporting limitations Product Comparison Chart Conclusion About the author Sources Page 2 of 26

3 1 Portal Analytics Overview With the various SAP NetWeaver Portal analytics products on the market, comparing and selecting the tool that best fits your company requirements can be an overwhelming and daunting task. Easy to read reports, secure data storage, proxies, caches and the sheer setup and implementation costs are only a few of the questions that you need answers to. This paper provides a comprehensive overview for developers, portal administrators and consultants who are looking for an analytical tool to streamline their SAP NetWeaver Portal. First we look briefly at the primary methods for collecting data within SAP Portal, and then we look briefly at SAP portal analytics tools and third-party analytics tools. Finally, we look at the individual aspects that can affect portal metrics and how each analytics solution addresses these issues. 1.1 Data collection methods There are two main methods of collecting data for general analytics and for specific statistics about portal users: Page tagging Server log files Page tagging Page tagging is a client-side data collection method, which means that it collects the information for analytics from the user s Web browser. This is done by adding page tags to portal pages along with the portal content. Page tags are simply JavaScript code snippets that are executed during page loading. The code collects specific information, including the reference to the current page via the cookies that the code creates. Collected data is then sent and processed by the vendor, and create and update the analytics reports. Server log files Collecting data from server log files is a server-side method that relies on the log entries created when the Web server requests pages. Those log files are then interpreted by Web log analysis software to build portal analytics reports. Even though there are several standard log file formats depending on your Web server, many Web analytics tools can create reports from different log file formats as long as they contain the required information. The page tagging method and the server log file method each have their own advantages and disadvantages, and you can also combine the two methods. This white paper gives you the key points of the two Page 3 of 26

4 methods and looks at potential issues with these methods, as well as how well-known third-party portal analytics tools implements. 2 Overview of SAP Portal Analytics Products In this section we review some popular analytics solutions that are available on the market, including analytics features that come with SAP NetWeaver Portal. 2.1 uses the page tagging method to collect user information. It is mainly targeted at advertisers to analyze whether their advertising model works as expected. Google provides this service for free with the expectation that you are a potential customer of Google through its advertising products, AdWords and AdSense. Therefore, it provides strong integration with those products. Figure 1: 2.2 was discontinued in 2012, but it is still instructive to look at how it works. Urchin gathers analytics data from server log files using one of two methods: Urchin can either process standard log information created by the portal Web server or it can enhance this standard information by adding page tags to portal pages. At the end, will read the available information in your server log files depending on the method you picked according to your business needs. Page 4 of 26

5 Figure 2: 2.3 offers two solutions: the SaaS solution Analytics On Demand and the software solution Analytics On Premises, both of which leverage the page tagging method as well as the log file server method. The page tagging solution works the same way as. On Premises offers a SmartSource Data Collector (SDC), which lets you use your own server to collect analytics data that comes from page tags. So, instead of using servers, you can define your own SDC-dedicated servers that receive data from page tags. Figure 3: 2.4 SAP portal activity report (PAR) One of the built-in tools that come with SAP Portal is the portal activity report. This tool gathers statistics about users logged on to the portal Page 5 of 26

6 as well as the content that the users view. Collected data is stored in a portal database, and an iview template is available for viewing reports. The iview template enables users to view different types of reports: Number of logged in users Detailed user information, including initial log-on, user ID, type of log on and hits Page/iView activity, information about hits, users and date/time for specific pages and iviews. All types of reports have a common setting for specifying the time period covered by the report. This period can cover the current day with a specified time range, the latest hours, days or weeks, or date range with selected time. The portal activity report tool has an option for exporting report data to a CSV file export. SAP Portal also offers predefined portal activity reports for system administrators. These reports include Last Week s 10 Most Popular iviews/pages, Number of Users in the Last 3 Hours and 10 Most Active Users. Figure 4: SAP portal activity report (PAR) 2.5 SAP activity data collector (ADC) SAP Portal comes with an activity data collector tool (ADC) that gives you more detailed portal statistics compared to the portal activity report feature. ADC monitors each portal request and maintains detailed information related to the requests. However, it writes collected information to raw text files only and does not display the data on the portal as with the SAP portal activity report feature. With ADC, you can specify the type of information to store, where to store the data files and how the information is written to the data files. These settings can be modified in the SAP Portal under "Service Configuration". Newer versions of the portal (EP 702 SP8 and above) have an editor that you can use to modify these settings in a more user friendly manner. You can specify the data to store, such as browser type, iview name, name of the logged-on user, user type, navigation path of the Page 6 of 26

7 iview/page, portal component triggered by the request, time of request and so some other data types (for the full list you ca n refer to help.sap.com). ADC can also maintain statistics about Knowledge Management (KM). You need to enable this feature after enabling ADC. With KM monitoring, you can trace any read, create, edit, delete, rename, copy and move operations. Figure 5: SAP activity data collector (ADC) report Figure 6: SAP ADC log file 2.6 (Adobe SiteCatalyst) uses page tagging to gather analytical data, which is then stored to Adobe s data collection servers. 2.7 by Sweetlets Compared to other analytics vendors, is designed specifically for SAP Portal. Therefore, it uses other collection methods for analytics data in addition to standard page tagging. These methods make use of APIs specific to SAP Portal, such as User Management Engine (UME) API and Portal Content Directory (PCD). is installed as portal component, which means that you do not to add additional page tagging code to the portal. Page 7 of 26

8 Figure 7: dashboard 3 SAP Portal Analytics Product Comparisons This section gives you an overview of different aspects that you need to consider when choosing a third-party analytics solution for your portal, as well as how each product handles these aspects. 3.1 Proxies and caches Caching can pose a challenge if you want to gather accurate analytics data. Previously visited pages can be cached into the visitor s browser cache, or a user s Internet service provider can cache pages into their proxy servers to speed up visits to the pages in the future. If users are behind a corporate network running proxy servers or accessing the Internet via proxy servers, subsequent visits to pages are replied to from the cache instead of the portal server itself. This is a problem if you are using server log files for analytics, because those accesses will not reach the portal server, and as a result no log entries will be recorded. The page tagging technique uses an invisible image to send the visitor data as parameters to this image request, and this image can be cached too. However, vendors avoid this by passing a unique number (e.g. the current date-time) along with the image request within JavaScript code. This will show each image request as a new request to the server. Hence, any visitor data will be collected without interference from the caching mechanism. Even though pages are cached, analytics data is always sent to Google s data collection servers as long as portal visitors have Internet access. The page tag in a cached page always generates a new request to the Google s servers each time the page is loaded. Therefore, your reports Page 8 of 26

9 will not be affected by pages called from proxies or caches instead of directly from the portal server. If you use Urchin without page tagging, pages requested from a cache instead of a server will not be recorded as an entry in the server log files. This situation will skew your metrics in the analytics reports. On the other hand, Urchin might overcome this issue with its page tagging method, which is the same idea applied by. The difference is that with Urchin the data collected by page tags are written to the server log files as well, instead of transferred to a separate server. As a result, whether or not your analytics reports will be affected by the cached pages depends on which method you choose to use with. The page-tagging code used by enables analytics data to be sent whenever cached views are involved. The SiteCatalyst page tagging code solves the caching problem by generating random numbers in its image request parameters for each visit. records navigation activity on the portal to prepare analytics reports. Therefore, any caching performed by the user s Web browser or proxy servers will not prevent from gathering analytics data. 3.2 Page-loading issues With the page tagging method, special JavaScript code is added to your portal pages, as mentioned before. However, this method only works if the page loads correctly and if the analytics page tag successfully collects the data needed from the user s browser. The issue is then what to do when a page does not load correctly. In coming up with a solution, we first need to look for possible causes of error in page-loading. It might be caused by problematic script on the page that stops the browser s script engine; in turn, the pagetagging code will not be executed. Partially loaded pages can also cause problems with the page-tagging method. Partially loaded pages can occur due to an interrupted connection, by the user manually stopping the loading process (for example, using the browser s Stop command) or by the user simply navigating away from a page before its contents are fully loaded. Again, in this instance, page tagging code Page 9 of 26

10 will not be executed. These situations are also related to where you placed the page tag code on the portal pages. You do not have to worry about this if you are using server log files for analytics because they record failed page loading as well as normal page loading in the log files after the page request reaches the server. Google suggests that you insert tracking code right before the closing <body> tag of your pages so that pages will not send analytics data unless they are completely loaded. If you are using the page-tagging method with Urchin, Urchin s online documentation suggests that you insert page tagging code after the META tags in the HEAD section. However, if you do not use the page tagging method, you do not need to modify any of your pages. recommends that you insert a JavaScript tag just before the closing <body> tag of your Web pages to ensure that an unsuccessfully loaded page does not send any analytics data. The SiteCatalyst implementation guide suggests placing a JavaScript tag at a top position within the body tag. This enables a page visit to be recorded if, for example, a user navigates away from the page before it is fully loaded. s page tag is inserted to the framework page of the portal, and it collects some data through the user s browser, such as the browser type and the screen resolution. If a page does not load correctly, then this information cannot be collected. However, because each requested page is already tracked on the portal server sid e, a large amount of analytics data is also already collected, and only some of the data is lost if a page does not load properly. 3.3 Export features You can imagine that changing the analytics provider of your portal might require much time and effort if you are using page tags, because you would then need to completely replace or remove the page tags that you added for your previous analytics solution. Also, considerable effort would be required if you want to use earlier analytics data with a new vendor as a common scenario. To migrate existing data to a new solution, you need to export the data so that your new provider can Page 10 of 26

11 parse it. You can overcome this issue if you previously used analytic software for log files, because server log files are typically available in one of the standard formats that can be parsed with many server log file analysis solutions. By migrating your previous log files to new software, you can then analyze earlier data along with the most current data. For analytics solutions that rely on page-tagging, you can only reprocess and reuse existing data or data from other vendors if the solution enables you to export reports. You can then use the exported reports as required for your scenario. enables you to export your analytics reports to three formats: PDF, comma-separated CSV and tab-separated TSV, where the number of rows in exported reports is limited. Urchin supports three different export formats: plain text, XML and CSV. You can also define the number of rows that can be exported and displayed on the Urchin user interface. supports Microsoft Word, PDF and CSV export options, as well as a special database exporting option to use with SmartReports, which is a tool for creating reports to view in Excel. SiteCatalyst supports PDF, HTML and CSV export options in its reports. supports CSV export with three different delimiters: comma, semicolon and tab. You can also save report visualizations as JPG or PNG files. 3.4 Cookies, JavaScript and images Analytics solutions that rely on techniques involving cookies, JavaScript and single-pixel images might result in some issues with metrics. All the available Web browsers give users the option to remove cookies, disable JavaScript support and disable image loading, and user settings for these options can affect analytics. In this case, page tagging will not be able to track visits. Cookies can be blocked by a user s browser settings as well as antispyware applications and firewalls. In these situations, the sensitivity to third-party cookies is much higher than to first-party cookies, so an Page 11 of 26

12 analytics solution that uses third-party cookies will have a much higher rejection rate for these cookies than for first-party cookies. When cookies are rejected, users will be recorded as new users, which will skew the metrics in your analytics reports. Page tagging solutions will not deliver accurate metrics if users disable JavaScript support or image loading in the browser. If the browser does not support JavaScript, then visits to a page will go untracked. In addition, because page-tagging relies on using a single pixel invisible image to transfer collected information from a user s browser to the data collection server along with the image request parameters, this method also will not work if image loading is disabled in the browser. Figure 8: Firefox settings for clearing cookies depends on browser support for JavaScript, images and first-party cookies. Disabling JavaScript or image support of the browser, or a problem resulting from another JavaScript code on the Web page will stop the JavaScript engine of the user s Web b rowser. Urchin s page-tagging method is similar to, and it allows you to use together with Urchin. The only difference is that while sends the analytics data to Google s data-collection servers, Urchin lets the portal server write the analytics data into the server s log file. Urchin can then parse the log files and create reports. Previously mentioned issues that can arise through lack of support for cookies, JavaScript and images can skew your analytics report if you use Urchin with the page-tagging method. Using Urchin with the log file method without any page tagging information can act as a workaround; however, this would limit Urchin s reporting features. Page 12 of 26

13 Both versions of Analytics (On Demand and On Premises) use the page tagging method to collect data on user activity. While On Demand is a solution hosted by, you can use On Premises on your server and use the SmartSource Data Collector (SDC) software to process tagging information. Reliance on JavaScript, first-party cookies and images can still result in the problems mentioned previously because both options still use page tagging even though the On Premises version lets you host the data on your own server. SiteCatalyst uses the page-tagging method. It sends collected user information through an invisible image request to SiteCatalyst s data collection servers. Dependency on JavaScript, first-party cookies and image loading can still result in issues mentioned previously. SiteCatalyst offers a server-generated image tag implementation without using JavaScript to avoid problems resulting from JavaScript. also uses page tagging to record user activity. However, the method is different from other vendors. Firstly, it sends analytics data directly to a database defined by the user in the software package, whereas other vendors send user information through the parameters to an invisible image request. Secondly, Click Stream does not use cookies to track user history and redirected pages. Instead, user-related information is gathered from SAP s User Management Engine (UME) API. This also allows to track the same user on different devices. 3.5 Real-time reporting and real-time data Real-time information can give you valuable insight into portal usage. Vendors can offer reports that refresh themselves regularly to reflect real-time data, or they can offer reports on-demand that show realtime data. Real-time data gives you get instant answers to questions like the pages that are being visited by which users, the users who are currently logged on to your portal, and the load distribution on your servers for identifying any bottlenecks. Server log files are written in real time, so software solutions can potentially take advantage of this to generate real time reports. Page tags can also send data from a user s browser to data collection servers in real time. However, many page tag-based analytics vendors do not do this due to resource restrictions - continuously collecting data from all clients can be an expensive scenario. Page 13 of 26

14 Figure 9: Example of real-time reporting with Due to the vast amount of data collected for all users and the geographical propagation of the data collection servers, reports are updated each hour using the data collected 3 to 4 hours earlier. In some cases, if there is an interruption when transferring log files to Google servers, it might take 24 hours for reports to reflect changes in data. The significant time lag in data delivery can be a concern for some users of portal analytics. However, does offer some statistics in real-time, for example, the number of active page visitors (this feature is still in its beta phase). Urchin analyzes the server log files to generate analytics reports, regardless of whether you choose the page-tagging option. It comes with a scheduler that you can define to process server log file on an hourly, daily, weekly or monthly basis. Urchin enables you to generate analyses on demand with the click of a button on the configuration interface, although it does not provide continuous real-time reporting features. Some of the metrics (Page Views, Visits, Page Views per Visit, Visitors, and New Visitor) are updated hourly. You can get realtime data on demand, but automatic real-time reporting is not available. claims that their reports are real-time, but they do not explain how this works. Page 14 of 26

15 offers real time reporting for last visited pages and server load distribution. These reports are updated automatically at a regular frequency as long as these reports are open. All other reports can be refreshed on demand to give you real-time data. 3.6 Setup and implementation costs This section looks at potential costs as well as time and effort involved with implementing each solution. is a free tool; however, in order to ensure correct implementation and accurate reporting, you still need additional staff dedicated to analytics and maintenance of the tool. Simply adding Google s tag to your portal will not result in readable reports unless you provide the necessary values such as correct navigation path names of your portal to Google. Therefore, might seem a cost-effective solution at first glance, but if you have a more complex Web site, you might find that you require lots of extra staff and effort to use the tool effectively. Urchin software installation is straightforward, although you will need to add JavaScript tags to your portal pages in order to collect more detailed data. You need MySQL or PostgreSQL installed on your system, and you also need to create a database to store analytics data. To generate analytics reports, Urchin needs visitor data found in the server log files in a specific order and amount. It supports eight predefined log file types and allows you to create custom log files to specify the order of data that it looks for. If you decide to use Urchin with its standard log files, you only need to provide your portal server s HTTP access log files in a format that Urchin can read. However, you can also use the Urchin Traffic Monitor (UTM) method, which requires JavaScript tags to be inserted in your portal pages. The JavaScript tag generates a request to an invisible image file along with collected visitor data on its parameters. Hence, log files will also include this request, which Urchin can read. If you use the UTM method, you get a logging mechanism that can also write cookie information in the log files along with standard HTTP requests. You need to purchase a project to integrate into your portal. Page 15 of 26

16 You need to purchase a project to integrate into your portal. The setup is already specific to SAP portal. To integrate, you install portal package, add the JavaScript tracking iview to the framework page of your portal, and assign roles to the users who are going to use the application. 3.7 Data storage time frame Analytics reports are more meaningful when you have access to data that covers a significant period, allowing you to compare data past and present and giving you the information you need to enhance your portal in the future. Analyzing the server log files is an easier way to keep track of history, but page tagging vendors should also give you a sufficiently wide date range so that you can easily compare historical data. Google keeps your data on their server for 25 months and does not guarantee data storage beyond that. If you want to keep your reports for a longer period, you need to export them locally into one of the available file formats. Urchin stores data in MySQL or PostgreSQL on a server that you specify, so you can define how long to store the data. However, for performance reasons, Urchin applies a size limitation to each table in the database. With On Demand, the license you purchase determines the data storage time frame of your reports. For the software version, On Premises, storage time depends on your analytics server. The purchased license determines the data storage time frame. There is no limitation on data storage time frame with, since you store data on your own servers. Page 16 of 26

17 3.8 Reprocessing analytics data Your portal may not always send the correct analytics data due to portal maintenance or other errors that are not as obvious. To ensure that you get accurate reports, you need to have a strategy for reprocessing data if you discover errors in the data. Ideally, analytics vendors will provide a way to discard erroneous data and let you reprocess the reports using the correct data. Any data that tracking code (GATC) collects is added to latest reports at. If you discover data errors due to problems with your portal or page tagging, you cannot interrupt the data collection process. The result is that your reports will reflect the faulty data, and you have no option to return the reports to an earlier state with clean data. With Urchin, data can be reprocessed because Urchin works with raw log files. However, Urchin has a mechanism built in to prevent the reprocessing of data, so as a workaround you might need to remove all data residing in the Urchin database before you can reprocess the data. On Premises allows you to backup and restore the analytics data, and this can be done on a scheduled basis. However, you cannot correct any erroneous data and upload again to get reports that reflect the correction. On Demand does not provide a way to reprocess data. does not offer an option for reprocessing data. Collected analytics data resides in the database that customer provided, so it is possible to edit data if you discover errors. However, you might require support from the vendor. 3.9 User and group activity data With analytics tools, you can gain valuable insight into the behavio r of individual users and user groups on your portal. Depending on the tool, you can find information such as click paths, user information and comparisons of user activity. Page 17 of 26

18 You cannot track the activity of individual users with due to Google s privacy policy. User data is aggregated and uploaded to Google s data gathering servers in a way that maintains user anonymity. With your data is hosted on your own servers, so if your log file format allows for including information on individual users, such as the user name, you can get statistics like page views and bytes downloaded for each user. enables user activity reports via customized JavaScript tags. User information is passed via tag parameters. If your portal doesn t provide user information, you can still use this parameter with the other identifier values (IP address and time stamp) provided by data collection server. does not provide any individual user-related information. provides rich user-related reports. These include duration, number of pageviews, portal user ID, name of the user, user activity based on roles and groups, countries and cities of users, and, if you define these options, user activity by company and department. Portal administrators can also decide to keep this data anonymous so that user information such as name and ID will not be shown on reports Intranet optimization Whichever analytics solution you decide on, you need to make sure that it is appropriate for your company s intranet setup. Some company intranets have different corporate portals for each company department, and for data security reasons, they can be located behind a firewall. In this situation, you cannot track portal users if you are using an on-demand analytics solution, since these solutions need to send data to the vendor s servers via the Internet. If your company intranet does not allow Internet access or is behind a firewall, then you cannot use, because Google s Page 18 of 26

19 tracking code cannot send any data to the Google servers under these circumstances. Urchin s user interface allows you to provide log files through the browser and four other methods: FTP, HTTP HTTPS and UNC pathnames. This means that you can use Urchin in your intranet as long as you specify the path to the log files. uses the SmartSource Data Collector (SDC) software to forward visitor data from page tags to a dedicated server that you specify. You can use this with Microsoft IIS in a Windows environment, but there are restrictions to using the Apache Web server in a Linux environment. is an on-demand analytics vendor; therefore, it needs to connect to Adobe s data collection servers. does not require an Internet connection to collect analytics data because it collects data to your own local database User privacy Internet users today are more aware and concerned than ever about protecting their privacy on the Web, and how an analytics solution collects user data can have an effect on your resulting analytics. If you use an analytics tool based on client-side data collection, it will use the JavaScript tagging method, which makes an additional call to the vendor s server (via DNS lookup). In this case, users will see that they are being tracked because this method creates cookies on the user s computer, and the call to the vendor s server will also be obvious to the user on the browse s status bar while a page is being loaded. More sensitive users might see that they are being tracked and, as a result, disable JavaScript support in their browser or block cookies. Some browser add-ons like AdBlock Plus can even block analytics script by default, depending on the user s filter settings. In these cases, you might prefer using a server-side analytics solution, which collects data from the requests coming to the server where your portal pages are hosted. Page 19 of 26

20 Figure 10: AdBlock can block specific JavaScript libraries for tracking purposes uses a client-side data collection method that sends information to the vendor s servers users can see this by the additional GATC URL that is requested when a page is loading and through the cookies created on the user s computer. As mentioned previously, visitors can disable JavaScript support in their browser or block cookies. If you are using Urchin with its UTM method, it will collect the user data from the JavaScript code that you added on your portal pages. Therefore, same considerations for are valid in here as well. However, if you use Urchin with its IP+User-Agent method, data collection only depends on the available server-side information. This limits the analytics information you get, but will avoid user privacy issues that might skew your reports. On Demand and On Premises use the page tagging method on the client-side, so it will be obvious to portal users, through DNS lookups and cookies, that they are being tracked. If users disable JavaScript in the browser, and data collection via page tags is no longer possible, makes it possible to send some user information through HTTP requests without using script. This is a server -side method rather than a client-side method, so implementation depends on the server technology you use. uses the page tagging method on the client-side. Again, DNS lookups and cookies make users aware that they are being tracked. is installed as a software package to the portal. This means that the only DNS calls made are to the portal server, and no additional DNS lookups are involved. So users remain unaware that they are being tracked. As mentioned in the previous section, Click Stream has the ability to collect detailed user information, but a Page 20 of 26

21 special feature enables you to keep the data anonymous for collection and reporting processes Corporate data security In choosing an analytics solution, an important issue to address is data security and confidentiality. Depending on what your company security policy is, how and where your company s data is processed and stored can be a key aspect. If your company does not want to maintain additional hardware and software for analytics, then you might consider a hosted solution, with the trade-off that your data is then collected and processed by the vendor, and not within your company. If your company wants to ensure that its data remains internal and confidential, then you need a server-side solution. This section looks at each product with company data security in mind. Figure 11: options for data sharing With, data collection and processing is performed by Google, so you need to be aware of the possibility that Google might share your analytics information with other Google services and third parties. Under the analytics settings, Google gives you the choice of sharing your data "with Google products only" or "anonymously with Google and others". Both data collection methods used by Urchin involve writing the analytics data into a database that you created on your machine. The only Internet connection that Urchin needs is to verify the license that you purchased, so your data remains within your company. Therefore, Urchin might be the better Google option for you if you are concerned about sharing your analytics data with others. Page 21 of 26

22 Similar to, On Demand also collects and processes your data on its own data collection servers, which might be an issue for some organizations. However, the On Premises software solution sends your data, via the SmartSource Data Collector (SDC), to your company s server, thus giving you better data security. sends the collected analytics data to Adobe s data collection servers, which might be an issue for some organizations. collects the analytics data into a server that you specify, so all data resides in your company. MS SQL, Oracle, IBM DB2, and SAP s MaxDB are supported. You can either use an existing database or create a dedicated database for Data and reporting limitations Your analytics vendor might apply some limits to the amount of analytics data that your portal pages send, as well as the reporting features available to you. This section gives you an overview. With, there is a limit to the number of hits that your Web site sends. According to Google, "Each pageview, e-commerce transaction, custom variable or event triggered on your site sends a hit to." and " a single view of a web page can send multiple hits to ". If your portal sends more than 10 million hits each month, any hits exceeding 10 million might not be processed unless you are a Google AdWords customer. Again, if your Web site sends 1 million hits per day, your report will be updated once a day, which means that some metrics will be updated every two days. The only limitation that comes with Urchin 7 is the limitation it applies to the tables in its databases. The standard record limit for its tables is 10,000, but you can set it to 10,000,000. Database tables are archived monthly, and if your records reach this limit before the rotation, your upcoming analytics data will be ignored. Some of the reporting capabilities that come with On Demand and On Premises depend on the license you purchase. These Page 22 of 26

23 include the type of report you can use with your analytics data, the number of service calls to the data collection server during a period of time, and the number of reports that you can export. The user interface also enables the user to check the number of accumulated server calls in a user account. Another limitation comes with the size of the tables that are displayed when you view your reports on your screen, as well as the tables that provide data for the reports. For both tables, if a certain size limit is exceeded, your analytics data will be lost and performance problems may occur. For On Demand, you need to request a table size increase from support. For the On Premises version, you can increase table size via the user interface. The license that you purchase determines the reporting capabilities. With, you get the full set of reporting features when you purchase the license, which in turn depends on the number of portal users. Page 23 of 26

24 SAP Portal Activity Report SAP Activity Data Collector (page tagging/server log files ) (Adobe SiteCatalyst) SAP NetWeaver Portal Analytics 4 Product Comparison Chart Collected data * *** ** ** ** ** *** Reporting capabilities * * ** ** *** *** *** Real-time reporting * * * * * ** 3 *** User and group-related reports ** ** * ** ** * *** Data limitations 1 *** *** * ** ** ** *** Proxies and caches *** *** *** *** / * *** *** *** Problematically loaded pages *** *** * * / *** * * ** Export features/switching analytics vendor ** * *** ** *** *** ** Cookies, JavaScript and image handling *** *** * * / *** * * ** Setup and implementation costs *** *** ** * * * *** License fee 2 *** *** *** ** * * * Data storage time frame *** *** * *** ** ** *** Reprocessing analytics data * *** * *** * * ** Intranet optimization *** *** * *** *** * *** User privacy *** *** * * / *** * * *** Corporate data security *** *** * *** ** * *** 1 More stars represents low data limitation 2 More stars represents low licensing fee 3 Could not verified Page 24 of 26

25 5 Conclusion As this paper shows, there are many aspects to consider when deciding upon an analytics solution to implement for your SAP portal. There are issues of cost and effort, technical considerations, data security and privacy aspects to think about. Each of these factors can have a potential impact on your portal metrics and, ultimately, can affect your portal development and ROI. If you have any questions about this paper or have general questions about choosing an analytics tool for your portal, feel free to contact us at info@sweetlets.com. You can also visit our pages to find out more about how it can help your portal. A free trial version is also available for you to try: About the author Baris Oztop is a Computer Science graduate student, currently at Stanford University. 5.2 Sources plementationguide.pdf rc/library/pdf/igod/webtrendsanalyticsondemandimplementa tionguide.pdf ml#dcapi aspx?id= amqlaai&r=1 m SAP Activity Data Collector (ADC) ae-2b f068636c8b1e 99ce a42189d/frameset.htm Page 25 of 26

26 SAP Portal Activity Report (PAR) ff996b827f2a06f9b1/content.htm Omniture 14usermanual Online resources have been removed, since Urchin is not available anymore. Sweetlets SAP Portal Applications is a product of Pentland Firth Software GmbH Unterer Anger Munich Germany Phone: Website: info@sweetlets.com Page 26 of 26