The
...
Prerequisites and installation
The storage and request of the events of the application is ensured by an Elastic server .
It will therefore be necessary to have a Elastic server in order to be able to store and view these statistics.
In addition to storage in Elastic all events are logged in a log file located in the administrative directories of Wedia and allow you to replay events if necessary.
Elastic Server Installation
The basic installation consists of downloading the latest version of Elastic 5.x or 6.x since and start it on a server.
The ElasticSearch instance can be deployed locally on the Wedia server or on any other server accessible by the latter. It is also possible and advised in production to deploy an entire ElasticSearch cluster.
You will find more information on installation, parameterization and configuration tuning Elastic on the site of link: official documentation for your version.
Caution | Only versions 5.x and 6.x of Elastic are fully supported by Wedia at this day. Please do not use 1.x versions anymore. |
Once the Elastic server is started, just go to the system settings of WXM /admin/ebnAdministration.ebn and to enter the following information the URL of one of the Elastic servers and the prefix to be used for storage statistical events.
Analysis configurations
A configuration can be defined as an entry point in the analytic system for storing events.
A configuration is always constituted of :
a configuration name,
series of events.
Events are made up of:
a timestamp
a set of parameters defined by the system known as
contextual parametersand are common to all events.a set of event-specific parameters
Dashboards
Analysis results are displayed in dashboards that can be used to can be viewed via the analytics action of the back-office V3 at the URL /wcm.jspz?form_action=analytics.
These dashboards make it possible to view the results of analyses for different evaluation configurations that exist in the system.
The buttons for accessing the dashboards allow you to navigate between the different statistical dashboards.
Clicking on the date allows you to access the calendars that allow you to set the date of the statistical period.
Statistics are always displayed over a period of time. The default time period is 30 days.
Note | Regardless of which graphic components are used on the different paintings they are always attached to a period of time. If the time period is changed by the user then all the graphical components will be updated with the period data. |
Data vizualisation
Statistics data can be viewed in several ways according to requirements via graphic components:
in the form of histograms allowing to visualize the events of events over a given period at fixed time intervals. For example, see the number of daily connections for the current month.
in the form of allocations allowing to visualize groupings of events over the period according to a given criterion. For example, view the different languages of the users' logon over the period. These distributions can be represented as pie charts, graphs in columns or tables.
in the form of counters allowing to visualize a number relative to the events over the period. For example, the number of different users over the period.
in the form of tables allowing to visualize events such as that they were recorded in the system.
Histograms
These graphs can be used to represent the events as they have occurred over a given period of time at regular intervals.
This histogram shows the DAM activity on the month of january 2019.
The time interval here is one day. Each column represents all the events that happened every single day.
Interactions with the graphical component
Clicking on a column will adjust the viewing period from the dashboard to the period represented by the column.
It is also possible to select a time range directly on the graph by clicking on the graph and moving the mouse. The highlighted area will represent the new time period.
Whichever method is used, the new time period will then be updated and the dashboard will be redesigned by taking into account only the events that occurred during this period.
Data distributions
These graphs are used to represent distributions of data in events recorded in system configurations.
For example, if you want to visualize the distribution of connections by role to the system it will be possible to choose the representation by this type of graph by displaying the result as a pie chart.
The distribution graphs can be presented in different forms.
Pies
Columns
Tables
If it is present, the user will be able to change the representation mode (pie|column|table) by choosing the display mode that corresponds to him most in the dropdown list.
Interactions with graphical components
The components are interactive and it is possible to click on the results to add filters to all dashboard graphics components. As previously seen on the histogram graph where clicking on a column allows you to refine the results period, here clicking on an element allows you to add an event filter.
By clicking on the Download of the action pie for example (or column Download on the graph in columns or line Download of the table), the dashboard will be automatically updated by displaying only events related to the Download action.
Clicking on the label in the legend will exclude results events.
It is possible to combine filters by clicking on the results of a graphical element then by clicking on the results of another graphical component. Filters will be combined to each other.
Active filters are displayed at the top-left side of the screen.
Tip | Green filters indicates that only results having the given criteria are displayed in the current dashboard. Red filters indicates that results having the given criteria are excluded from the current dashboard |
Simple values
This component displays a simple event counter. It is possible to count either the total number of events according to a criteria over a given period of time or the number of separate events on the same criteria.
For example, the first can be used to count the total number of connections on the system, the second can count the number of different users who have logged on the application.
...
WEDIA engine ships with default logs that are analyzed by the Analytics system.
These logs record all the system events produced on the application when the user carries out certain actions like for example:
connection to the system,
creations, modifications or deletions of contents in the application,
downloading a DAM asset into a shopping cart,
etc.
They are the source for all Analytics dashboards.
There are several system configurations:
sys_accesslogs related to all HTTP access events
sys_gates for all events related to system performance monitoring
sys_connection related to all events connected/disconnected in the system
sys_objectdata for all events related to data access
| Table of Contents |
|---|
sys_accesslogs
This configuration records all HTTP accesses made on the application.
It records more or less the same information as that stored in the the access logs of the application server.
It does, however, add a number of useful indicators that do not exist in standard access logs that allow you to trace a user’s entire browsing experience during a session via system settings.
In addition to the standard contextual parameters, this configuration uses the following parameters:
http_content_type
The standard content of the HTTP response (ie:"text/html") http_length
Size of the HTTP response in bytes http_method
HTTP method (i.e.: POST) http_status
HTTP response status (i.e.: 200 | 302 | 500)
http_version
HTTP protocol version (i.e.: http/1.1)
time_started
UNIX timestamp of the start of the query (i.e.: 144844889797127)
time_ended
UNIX timestamp of the end of the query (i.e.: 144844888897131)
auth
User login (in the case of basic authentication)
sys_gate
This configuration is used to record events related to monitoring application performance.
It is reserved for internal use within the Wedia engine and will not be detailed in this documentation.
sys_connection
This configuration is used to record events related to connections and disconnections in the system.
In addition to the standard contextual parameters, this configuration saves the following parameters:
actionid
The action performed by the user. This action may include three different values according to the events:
loginok when a user successfully logs in
connectionbad when trying to connect failed
logout when a user logs off
badlogin
If the actionid=connexionbad connection fails. Stores the login with which the user tried to identify himself.
sys_objectdata
This configuration records all events related to the application contents (insertion of contents, modification, deletion, views and download, etc …).
It will help to visualize precisely which contents are the most contributed in the application, which are the most seen, which user has interacted with which contents, etc.
Those events are automatically handled by the application in objects triggers and in the standard back-office pages (BOV3). Projects developers may need to log extra events in their front-offices or in custom back-office page. This can be done thanks to the LogEvent API (see dedicated section).
In addition to the standard contextual parameters, this configuration uses the following parameters
objectuid
UID of the object on which the event occurred. For example: material_122 (material with ID property equal to 122) objectname
The name of the object on which the event occurs actionid
The ID of the action, this parameter can take one of the following values
insert in the case of
creationof a new instance of the objectupdate in the case of
modificationof an instance of the objectdelete in the case of
deletingan instance from the objectview when the user accesses the
fileviewaction of the objectdownload when the user
uploads the native resourceof a DAM content object
More action may be used in your application (see dedicated section)
statusuid
The UID of the status if available damobject_suffix
The suffix of the main resource in the case of a DAM object damobject_type
The main resource type in the case of a DAM object
...
For each tracked-event of an instance of an object in the system we will therefore be able to find through these parameters
what is the instance on which the event occurred,
what was the status of the instance at the time the event occurred (if available)
what is the suffix and type of the main resource if the instance is a DAM element
etc.
In addition, thanks to the contextual parameters we will also know of the following information:
which user performed the action,
what was this user role,
what was his language of contribution,
what was the session in which he carried out the action,
what his IP address was,
from which application page did the event occur,
from which page of the application the user came before the action occurred,
what browser the user was working with,
etc.
and of course when did this event occurred.
Logging extra events in sys_objectdata configuration
Although sys_objectdata is a system configuration it is possible to programmatically trigger events in this configuration.
Indeed on a front office it may for example be preferable to notify the sys_objectdata configuration that an asset has been downloaded by a user without creating a dedicated configuration for that front office.
In this case, the sys_objectdata configuration can be used to record events related to content objects such as:
download
viewing
copy
synchronization
users votes (likes, stars, etc …)
etc.
The production of events is dealt with in the chapter on application configurations.
Logging extra content parameters in sys_objectdata
Since 11.11.0 it is now possible to add custom content parameters to the default sys_objectdata configuration.
Simply add the structure field tag analytics/sysobjectdata/extra on any child or childmultiple or string property of the object to have it added to the event.
When available those parameters will be found under the extra property of the event parameters (ie. event.params.extra.propertyuid).
A custom parameter will always be retrieved with event.params.extra.VARIABLE_NAME.
The uid suffix at the end of the parameter name is automatically added by the application on child and child multiple properties.