Webtrends mobile application development FAQ


Webtrends Analytics 9.x


Q: For iOS4 support, didEnterBackground and willEnterForeground are not managed by WTDelegate. How is “fast app switching” is supposed to be managed? Compared to sessions? Currently “stop signal” is only sent when the apps send the event “appWillTerminate”?

A: You can manually pass the Webtrends app start and app terminate methods anywhere you wish. This is so apps would not be inundated with events in case developers want to be minimal with the data sent. It’s easy to send more data but not as easy to remove events.

Q: Is eventForAction counted as a page view?

A: We pass a parameter wt.dl=60 which, by default, does not get included in page view counts. Use eventForContentView for page view events.

Q: How are page views counted? Should we use eventForContentView?

A: Use the eventForContentView for page view events.

Q: What is the purpose of the contentGroup?

A: Webtrends has content group reports in which groupings of application screens can be created. For example, you could create a “Settings” group, etc. and these will show up in the “Content Group” report in Webtrends.

Q: If the mobile app is waken up by a notification should we create an eventForAppLaunch using WTLaunchStyleFromNotification style? Does the SDK create a second event automatically? It seems the SDK creates an eventForAppLaunch (WTLaunchStyleFromHomeScreen style) in this specific case.

A: Yes, we are automatically launching the Webtrends event eventForAppLaunch with the “from notification” flag when a notification is received. There is no need to pass this manually in your code unless you aren’t using our app delegate instrumentation.

Q: Can WTAppDelegate be inherited? If yes, why? Is it possible for it not to be inherited while managing start and stop events?

A: Yes, it can be inherited, and this is so that common events can be handled automatically. It is also possible for it not to be inherited and to manage start and stop events.

Q: Do multiple app launches in a short period of time create a single session or one session per launch? How do you measure session length? Describe the following parameters and their impacts: wt_dc_session_maximum and wt_dc_session_timeout.

A: Multiple launches count as one session unless there has been a measurable period of no activity. By default, sessions are visits of thirty minutes in length and thirty minutes of no activity will trigger a new session on the next event. The wt_dc_session_timeout value defaults to 30, denoting the number of minutes from the open of session and/or the last event, after which the session closes. The wt_dc_session_maximum value defaults to 480, denoting the number of minutes (eight hours) for the maximum length of a session. For visitors browsing continuously for eight hours, this will forcibly close their sessions. A new session opens if they continue browsing.

Q: Can we precisely measure periods of time such as how long a user stays on a page? How much time is needed to launch the application before the first page shows up?”

A: Yes, this is done automatically. Webtrends notes the first event time (app start) and when the next event occurs it calculates the time between events and then attributes this as a “time on page” value for the initial event. It does this for each succeeding event as well. This is not completely accurate because it’s possible the visitor let the app go idle. To get the most accurate metrics, pass your own event even when the app is idle or in the background.

Q: Do you plan to manage events as a queue line and send them at a given time?

A: We already queue events. We take into account various factors on deciding when to queue an event (battery level, offline mode, poor connection) and messages are queued and sent at times when connectivity and hardware-related issues are not a factor.

Q: Can we use Webtrends mobile tracking solution on all operating systems, even if no SDK is available? What SDKs are available?

A: We have pre-built SDKs for iPhone, Android and Blackberry, but all three are use our Data Collection API (DC API) as the mechanism for sending the data. Anyone can create DC API requests and send them however they wish on any platform. They are easy to make (they are HTTP POST requests with name/value pairs for parameters) though familiarity with the basics of Webtrends parameters is required. Documentation on the DC API is available at the following URL:


Q: Can POST requests be sent by both HTTP and HTTPS using Webtrends Apps?

A: Yes, the DC API supports both HTTP and HTTPS, with the default being HTTPS. We prefer and recommend HTTPS in all cases but that is up to the developer.