1 Introduction
Collecting and analyzing clickstream data is growing since the increase of usage in ecommerce and applications. The focus is mainly of on purchasing and prediction of customers’ purchase behavior [19, 1, 14, 9, 15, 2, 22]. However, there have also been attempts to analyze the customer behavior with respect to the usability of web or application design [4, 20, 21, 7]
. In general, clickstream data can be considered as a sequence of log events collected at different levels of web/app usage, such as client or server level. It can be also considered at different levels of granularity, for example, page visits or action clicks on each visited page. The analysis of clickstream data has developed in several directions during the previous years. Some of the works focus on feature extraction from clickstream sequences for further analysis
[4, 19, 14, 9]. There are some other works that use clickstream sequences as input data and perform sequence analysis methods directly on sequences [1, 15, 12, 20, 21, 23, 2, 22]. Path analysis is also related to this topic, where a specific path is defined and customer behavior is analyzed through this path to identify possible problems and bottle necks [7, 13]. For analyzing the customer behavior towards quality analysis of application design, extracting features or doing path analysis can be meaningful. However, such methods suffer from the lack of generality. In both methods, we define explicitly our focus of analysis from the beginning. On the other hand, generalized methods which analyze the whole clickstream sequences and try to find patterns to understand customer behavior, provide insights into the design problems, which are not clear from the beginning. In the works which consider the clickstream data as sequences, either perform classical sequence mining to find out, e.g., which pages were normally visited together [8, 17], or cluster the users by defining some similarity measures between the sequences [1, 12, 20, 21, 22]. These methods normally suffer from scalability and performance.Using graphs for sequence analysis in this domain is mostly limited to similaritygraphs and corresponding algorithms on similaritygraphs [23, 22]. In a similaritygraph, each node represents a sequence and edges represent the distance between nodes. In this sense, the graph is not used to take the structure of the sequence into account but is a tool for performing specific clustering algorithms optimized for similaritygraphs. Yet, representing the sequence in a graph structure has some benefits. In biology, for example, they use graphs to represent parts of sequences, due to the fact that graph structure is invariant under some transformations such as mirroring [5, 16, 11, 24]. In the domain of clickstream analysis, Baumann et al. [2]
use graph structure for modeling the clickstream sequences. They generate a graph for each sequence of click data and calculate graph metrics for that generated graph. Finally, they use the calculated graph metrics for further methods such as gradient boosted trees. They examine experimentally the importance of different metrics and showed, for example, that number of cycles and selfloops are significant metrics in prediction of customer purchasing behavior. But they loose the track of how many times a cycle was traversed.
A graph structure can capture the circles in a sequence and therefore provides a more compact representation of a sequence by counting the number of times a cycle was visited. It is specially the case if the sequences are the walks through a state automaton, which is the case in most of clickstream data from applications. Furthermore, if a sequence can be considered as a regular expression, then it can be reduced to a walk on a finite state automata as well [10].
In this work, we show how representing and saving the sequences with their underlying graph components, can induce a platform for customer behavior analysis. The main idea behind our work is that clickstream data produced from actions in an application are walks of the corresponding finite state automate (FSA) of that application. Each action corresponds to a state of the FSA. Our hypothesis is that the customers of an application normally are not using all the possible walks through that FSA but the number of real walks is much smaller than the number of possible walks through the FSA. The second point is that the walks (sequences) consist of finite numbers of cycles on FSA graphs. Thus, these walks can be reduced to their common graph components. These components capture information which is not completely covered in the common used methods such as kgrams pattern analysis in common sequence analysis. In kgrams method, normally the number of common long subsequences of two sequences is calculated. The correct choice of is crucial. The multiple attendance of a cycle is captured somehow by counting the kgrams but the meaning of the cycle itself is totally lost.
We show that representing the sequences through their underlying graph structure not only groups the sequences automatically, but also is a compressed data representation of the original sequences. This compressed representation, allows queries directly on the saved data in graph database. In the original sequence format, for each of these queries, an specific algorithm is required. In the following sections, we describe the data and formal definitions used in this paper. Afterward, we introduce our method how to convert sequences to their graph components. At the end, we discuss the possible designs in a native graph database and introduce specific queries which can be performed better in this concept.
2 Data
The data used for our analysis are log events of clickstream from application installed on board of a vehicle such as navigation, radio etc. It consists of sessions which can roughly be considered as a drive (it is still possible to have several sessions during a drive, depending on how a new id for a session is triggered). During a drive the actions of the user on the HMI (HumanMachine Interface) are collected by a eventlog mechanism. These events correspond to the states of a FSA. We consider the consequent occurrence of the states of an specific application during a session as a sequence of the clickstream for that application and user. The states in a sequence also have a timestamp which defines the order of the states in a sequence. A vehicle (user) can have several drives (sessions) over time. For each session, exists a sequence for every running application. Each sequence will be represented in its corresponding graph components as described in the next section.
3 Sequence to Graph Structure
3.1 Definitions
We define a graph with a set of vertices and edges as a directed graph, such that an edge is a tuple with starting vertex and ending vertex .

A (directed) walk in such a directed graph is a finite sequence of edges which joins a sequence of vertices such that for and is the vertex sequence of the directed walk.

A (directed) trail is a (directed) walk in which all edges are distinct.

A (directed) simple path is a (directed) trail in which all vertices are distinct.

A (directed) cycle is a nonempty directed trail in which the only repeated vertices are the first and last vertices [3].
Consequently, from these definitions implies that a directed walk can consist of several simple paths and cycles.
In our clickstream data from onboard application, each sequence is the succession of state transitions in the underlying FSA of that application. Thus, each state transition can be considered as an edge in a FSA graph and the whole sequence can be considered as a directed walk on that graph. Finally, these directed walks can be reduced to their components, namely simple paths and cycles. We introduce a method to split the sequences into their components.
3.2 Algorithm
As we discussed previously in section 2, a sequence is the consecutive occurrence of the states of the FSA graph of a specific application during a drive. We assume that for each two consecutive states and with appearing after in sequence , there exists a directed edge between those states in the FSA graph.
With algorithm 1, we split a sequence into simple paths and cycles. In general, other splits are also possible. The example below shows the result of our algorithm and an alternative split for a walk on an example graph depicted in Figure 1.
Sequence is a directed walk on the graph in Figure 1. The algorithm 1 reduces this sequence in following components:

a simple path:

three cycles:

a simple path:
An alternative split of the same sequence can be:

a simple path:

two cycles:

a simple path:
If we put the simple paths from first splitting together, we will have a simple path from vertex to the vertex , . Doing the same for alternative splitting, we will have which is no longer a simple path and include a cycle. We can show that the algorithm 1 always produce the maximal number of cycles. For this, we start with some theorems.
Theorem 1.
a simple path is a part of another simple path if and only if, the edges in appear in the same order in .
Proof.
By definition, every edge in a simple path starts with the end vertex of its previous edge. Thus, for two consecutive edges and in , we have and . If the path , has other edges between and , then it contains a cycle and it is not any more a simple path. ∎
Theorem 2.
a cycle with the number of its edges can not be part of an other cycle with length of where .
Proof.
Every vertex on a directed cycle has per definition exactly one incoming edge and one outgoing edge. If a cycle is part of a longer cycle that means, there are edges and vertices on the longer one which are not part of the shorter cycle. A cycle is a connected component. Therefore, these extra edges in the longer cycle must be also connected to the edges and vertices of the shorter cycle. This contradicts the condition of exactly one in and out edges on each vertex. ∎
From Theorem 2 follows that, a cycle is definite and clearly defined just through the set of its edges.
Theorem 3.
Considering only the simple paths found by Algorithm 1, these paths build a connected path from start to the end of the original walk (sequence).
Proof.
Considering a vertex on the given walk , which is not the last vertex, we have only one of the three possibilities:

either is starting point of a cycle,

or is the starting point of the next simple path,

otherwise, is in the middle of a path or cycle.
In case 1, at the end of the cycle, we will end again at vertex . So that will be again either a case 1 or 2. Considering only paths, that means a vertex at the end of a simple path, which is not the last vertex of the walk , is the starting point of the next simple path. This concludes that putting all simple paths together will result in a connected path from start to the end. ∎
Theorem 4.
The Algorithm 1 identifies the maximum number of cycles on a walk .
Proof.
Assume there exists a splitting of walk with cycles more than the result of algorithm 1. Without loosing the generality, we consider the n cycles with separate starting nodes in the same order in which they appear on the walk . So that, we have cycles , , …, . Suppose there is a simple path before the first cycle . The algorithm 1 has to find cycle or it finds another cycle earlier. If it finds another cycle earlier, can not be happen before , otherwise we have cycles in the walk . From Theorem 2 it can not be part of . This means that, either it has its starting point on the path and ends on the cycle, or it is completely inside the cycle . In both cases, the algorithm will find cycle , instead of . That means the cycle appears before other cycles. The algorithm either has to find the rest or we can induce our argument to the next cycle. ∎
It is to mention that splitting the walk differs from splitting the underlying graph into its components. The example in Figure 2 illustrates the difference. Let’s compare two walks and on the graph depicted in Figure1(a). Both walks start at vertex and enter the cycle at two different vertices and . The Figure1(b) illustrates the two walks with the edges of each walk marked with different colors. In Figure1(c), we see the splitting of the walks as a result of algorithm 1. Both walks are split into three components. Two simple paths and a cycle. They share the cycle but have different paths. The ending path of the walk is the part of ending path of the walk . Figures 1(d) and 1(e) shows the components of walks and from algorithm 1. On the other hand, we can consider the graph of each walk and split it by the cycles and non cycle parts of the graph as depicted in Figure1(f) and Figure1(g). In this case, the two walks share two similar components and only differ by their starting paths. It is just a matter of perspective, what we are interested in and what we see as more similar. In the splitting in Figure1(f) and Figure1(g), some information from original walks are lost. Both walks are running through exactly the same vertices, but their length varies. This means that some vertices are visited more often in one walk than the other one, which is visible in Figure1(b), as we are walking part of the cycle for a second time. This information is coded in the split in Figure1(c), so that the last paths differ. In this paper we consider that walk and walk only share one cycle, which they enter at different vertices.
We use algorithm 1 to split sequences into their components. In the next section, we show how we use a native graph database to save the sequences by their components and perform sequence analysis by querying the graph database.
4 Modeling sequences in graph database
In native graph databases, graph models play a central role. The graph model represents how we look into the data and which questions and queries we are interested in. In other words, our problem domain is reflected in our graph model [18]. In this chapter, we discuss several modeling scenarios for our sequence components and compare them with each other. we start with the problem description and discuss other aspects like performance and flexibility in the following sections.
4.1 Problem description
In our clickstream data, we are interested in the ways customers use our application in the car. The key analytical questions are, e.g., common problems like long common paths, or cycles, to fulfill a task, or clustering the customer according to their usage pattern of the application.
In the literature, there are methods and topics which address similar or related problems, such as funnel analysis. In contrast to our method, in funnel analysis, we first select a specific path and then analyze the behavior of the customers on that path [13].
The majority of the works on customer behavior and clickstream analysis is either focused on sequence analysis by sequence vectorization
[15, 12, 20, 21], or comparison of some key performance indicators [14, 9]. In most of these studies the patterns inside a sequence are coded and compared with each other but the meaning and shape of a single subpattern in the sequence is lost or not considered. In the method we introduced in the section 3, we split sequences into their underlying components such as simple path and cycle. These components can be compared, classified and grouped in the process of sequence analysis. For this, we save the sequences in form of their components in a graph database. Our models have a hierarchical structure and at each level of hierarchy we can save the corresponding meta data for that level of hierarchy. Figure
3 shows a modeled hierarchy for the clickstream data from vehicle’s onboard applications. At the top of hierarchy we have customers. Each customer performs several drives. During each drive different applications are used. For each application usage we have the corresponding clickstream sequence which can be split into its underlying simple paths and cycles by algorithm 1. In the example from Figure 3, application 1 in drives 1 and 2 shares components 2 and 3. Same application in drive 3 has totally different components than in drive 1 and 2.At each level of hierarchy we can have different attributes. A customer can have gender, age and address. A drive has a start and an end time, and start and destination positions. Application sequence has the attributes of application category, e.g. Navigation, Entertainment, etc. Each application can have its own specific attributes. Navigation, for example, can have the binary status if a routing calculation during the drive has started or not.
Each sequence itself consists of a finite number of components such as simple paths and cycles from the walk on the FSA of the corresponding application. In the next section we describe several scenarios how we can model these components in a graph database.
4.2 Modeling the sequence components in a graph database
As we discussed in chapter 3, a simple path can be clearly defined by the ordered list of its vertices, where the order defines visiting time of the vertex. A simple path has clear start and end point. From Theorem 2 follows that a cycle can be defined clearly by a set of its edges, while the order of edges in a set is not important. A cycle does not have a defined start and end point. It can be entered at any vertex. We start our models according to these mathematical definitions.
Suppose we have a set of sequences to analyze, with as the number of sequences in . The Algorithm 1 results in distinct cycles and distinct simple paths after computing on set . Lets be and the number of all edges and vertices of the cycles in (with duplicates). Analogously, we have and as the number of all edges and vertices of the paths in respectively (with duplicates). The sequences in are walks on a FSA graph. The FSA hast vertices and edges. In the following we use these numbers to compare different modeling variants.
4.2.1 Model variant 1
In the first variant we start modeling directly on FSA graph. We model distinct states of an FSA as defined vertices in graph database. Each path and cycle is marked with a new different edge between the vertices of FSA. Several edges can exist between two vertices. A simple example with three components in Figure 4, one cycle and two paths, demonstrate our model in variant 1. As we can see between vertex and we have three edges with different types for each component. In this model we have to create vertices and edges in the graph database.
4.2.2 Model variant 2
In the second variant, we save each component as separate vertices and edges as depicted in Figure 5. As a result, we have to create vertices and edges in the graph database.
4.2.3 Model variant 3
In the third model variant, instead of the vertices of the FSA, we save the distinct edges of the FSA as nodes (transitnodes) in a graph database. Each path and cycle is represented as a node and is related to its corresponding transitnodes. That means, components can share transitnodes. In Figure 6, the same example from Figure 4 is modeled as variant 3. For an FSA with vertices as directed graph, the maximum number of edges is limited to 2permutation of and therefore can be maximally . The number of edges stays the same as in version 1, . We have also to add extra vertices for representation of each path and cycle, which means extra nodes in database.
4.3 Implementation of models in a graph database
To prototype our models, we used the Neo4j community edition [6]. In general, the concept is independent from the graph database platform but still variation in the implementation of graph databases can influence the performance on different models. To clarify the used vocabulary in the discussion below we go through a short introduction of some conventions in Neo4j. In Neo4j, there are nodes and relationships, which can be considered as equivalent to vertices and edges in a graph. Each node or relationship has a type which acts like a classification, that means we can create several nodes and relationships of the same type. Each node and relationship can also have several attributes of different data types such as name (String), creation time (DateTime), visited (Boolean) etc. We use Cypher graph database query language, widely used in Neo4j community [18], for our expressions in this context. The below Cypher expression creates two nodes and a relationship between them. The nodes are of type State and the relationship is of type Cycle. and are variables. Type State has an attribute Name, which for the first node is Address Book and for the second node is Search Field. The relationship with the type Cycle has an attribute ID with value .
CREATE (a:State {Name:’Address Book’})[r:Cycle {ID:101}]> (:State {Name:’Search Field’})
4.3.1 Injection of cycles and paths
Suppose we have a set of distinct cycles and distinct paths to add to the graph database.
Injection in model variant 1:
In model version 1, we can create the states of the FSA graph at once. Then, for each cycle or path, it is enough to select its vertices in database and create the edges. Due to the relative small number of states, this task is performed in constant time. But Neo4j is not designed for multipleedges modeling. For creating multiple relationships between two nodes, there are several possibilities:

multiple relationships with same type and different e.g. name attributes, Neo4j does not support creation of such multiple relationships between two nodes from the available drivers. It is possible to create such relationships directly from the Neo4j desktop.

multiple relationships with different types.

single relationship with a list of attributes. Having paths as attribute entries in a list makes the queries on searching and selecting those paths inefficient because the graph database is optimized for queries directly performed on nodes and relationships.
In both cases, with multiple relationships,for both single type or multiple types, we have to check if the new path or cycle already exists. As we know from Theorem 1, a shorter path can be part of a longer path. Thus, such paths will cause problems by selecting them in model variant 1, because all the longer ones will be selected along with it. At the end, we have to perform more complicated queries to find out which of them are longer ones. Another disadvantage of this model is the assignment to its higher level. Because the distinction between components is modeled as edges, it is not possible to assign the parent level nodes (drives / sequences) by a relationship. We have to put this information at the attribute level, which again withdraws the benefits of a graph structure.
Injection in model variant 2:
In the model version 2, for every distinct component we create nodes and relationships between those nodes as a new component. The path or cycle can be distinguished by, e.g., its ID or Name at the attribute level on nodes and relationships. By every injection we have to check if that path or cycle already exists in the database. It can be performed by the following expressions easily.

For a path with n nodes:
MATCH p =(s:State {name: ’State Name 1’, title: ’start’})[r]> (State {name: ’State Name i’})> ... // all the nodes is between (e:State {name: ’State Name n’, title: ’end’}) RETURN r.name
The paths is clearly identified through its start, end and the nodes in between.

For a cycle with n nodes:
MATCH p =(:State {name: ’State Name 1’)[r]> (State {name: ’State Name i’})> ... // all the nodes is between (State (:State {name: ’State Name 1’)) RETURN r.name
The cycles need no start or end attribute, the only difference is that the start and end node of the match has to be the same. In this model we are saving the state nodes duplicated compared to version 1. On the other hand, we can assign the components to the parent nodes with an explicit relationship. Each drive can enter the cycle component at different nodes. Furthermore, the relationship between drives and their components can have timestamps to capture the order of the components in the walk. If the component dose not exist in the database, it can be added by replacing the MATCH with a CREATE.
Injection in model variant 3:
In the third variant we create the edges of the underlying FSA graph as nodes and assign them to the cycles and paths. The MATCH expressions to check if the components already exists, can have the following forms:

For a path with n nodes.
MATCH (c:Paths)[d:P]>(:T) WHERE ALL( x IN {start_end} WHERE (c)[:P]> ΨΨ//start_end is a list of tuples for each edge ΨΨ//with names of its start and end states. (:T {start: x[0], end: x[1]}) ) WITH c, count(d) as pathLength WHERE pathLength = length({start_end}) RETURN c.name

For a cycle with n nodes.
MATCH (c:Circles)[d:C]>(:T) WHERE ALL( x IN {start_end} WHERE (c)[:C]> ΨΨ//start_end is a list of tuples for each edge ΨΨ//with names of its start and end states. (:T {start: x[0], end: x[1]}) ) RETURN c.name
In this model, the edges are shared, hence even if the component itself has to be created, it must be guaranteed that the node for edges are added once. For this, we use MERGE instead of CREATE. MERGE is equivalent to MATCH before CREATE. Accordingly, a CREATE operation is faster than MERGE.
Injection of large amount of data:
If we have to deal with a large amount of data at once, it is better to avoid the single inserts due to lock latencies. For this, in Neo4j we can benefit from tablewise insertions, in which the node and edge information are provided rowwise in a table. The table can be uploaded in one step and will be internally processed row by row. In the case of variant 1, the problems already discussed in the case of single injection also persist in the tablewise insertion. In the model variant 2, we create for each edge of the components, a row in a table with a start, an end and a component id. In row wise insertion, first the start and the end nodes will be merged. Finally, the relationship between the start and the end of the edge will be created. In variant 3, we can have the edges per component as rows of a table and merge them to the database, the same way as in the single insertion.
4.3.2 Query the graph
Actually the main purpose of the data transformation into graph database, is to open the possibilities for data queries which in relational databases are either inefficient or even impossible. We concentrate ourselves on the example of several queries which play an important role in the analysis of customer behavior. At the same time, these queries do not perform well in traditional relational databases, particularly in the case of large amounts of data. Of course, we can always add explicit indexing on relational databases to mimic the benefits of nonrelational databases. The scope of discussion here is the benefits of nonrelational databases such as graph databases, and not the way we want to realize such designs.
Example 1:
Given a sequence of consequent states such as a simple path, we are interested in the customers who traversed exactly this simple path during the application usage. In a relational database, the data as described in section 2, has to be sorted per session and timestamp. Even if, the data is stored sorted, we still have to search the whole table (e.g. several T bytes) for the start state of the simple path and check the consequent states afterwards. In a graph database such simple paths can be searched at once with all nodes and edges. Experiments from our prototype show that the number of graph components converts. That means the search space is much smaller than the original table in the relational database.
Example 2:
We are interested to find out how many different paths the customers traverse between two states of interest and . The query itself will be similar to the example before, but the variation depends strongly on whether we consider the loops and the multiple traversal of the loops or not. Identifying loops is not straightforward. However, the component based storage of the clickstream data makes it possible to identify such structures.
Example 3:
We are interested to find out in which loops the customers are stuck most of the time. Firstly, finding the loops itself is not straight forward. Secondly, we have to be able to count the loops as the same loop even if, they appear with different starting points in the sequence. Here is an example; and are the same cycle. For these kinds of analysis we have to extract data and solve our questions algorithmically. The components wise storage of the sequences allows us to perform such analysis as queries. We can also combine it with similar reasoning as funnel analysis, such as considering loops appear in a path of interest.
Example 4:
One of the main focus of click stream analysis and customer behavior analytics in literature is sequence pattern mining. They usually use methods of vectorization such as kgrams to map the sequences to vectors and define metrics on them [22]. Finally they use known vector based pattern mining methods such as clustering. In this work, we have introduced component wise analysis of the sequences. The main hypothesis is that the sequences consist of cycles and simple paths which they share. In other words, we can compare and group the sequences according to their common components. In our prototype, we can cluster the sequences into clusters of the exact same components. The clustering itself can be performed by a single query and can be restricted easily for further analysis.
The first two examples are query based analysis which show the benefits of a graph database storage while the third and forth example highlight the benefit of componentwise analysis of the sequences.
5 Result
For our prototype we used a subset of the data described in section 2. The subset consists about 200 k drives within two weeks and is about GB in size. For the storage in the graph database, the following steps were performed:

Extracting the sequences per drive.

Deriving the components of the sequences.

Insertion of the sequences and their components into the graph.

Insertion of customerdrive nodes into the graph and assignment to the sequences.
The created result in the graph database is less than 500 MB large. We have achieved roughly a space reduction of 10x. We implemented all the three model variants described in section 4.2. All three models result in a similar storage amount of 500 MB. In what follows, we compare the model variant 2 and 3 by performing the queries from examples 1 to 4. Table 1 gives an overview of the subset used for our experiments according to the numbers introduced in section 4.1. Table 2 summarizes the number of elements in each model. It also shows if the element is modeled as a relationship (edge) or a node.
Quantities  number 

number of sequences drives  224265 
number of distinct cycles  3767 
number of simple paths  7438 
total number of edges or vertices in cycles  16077 
total number of edges or vertices in paths  25736 
number of vertices in FSA states  124 
number of edges in FSA transits  1691 
Seq. Components  
Vehicle  Drove  Drive  Has  Circles  Paths  State  Transit  
NodesV2  85975    224265        49375   
EdgesV2    224265    1570774  16077  25736     
NodesV3  85975    224265    3767  7438    1691 
EdgesV3    224265    1570774  16077  25736     
In the first query from example 1, we search the database for all drives which have passed through the simple path , where the numbers 1710, 552 and 574 are the states’ IDs. The search query in model variant 2 looks like this:
MATCH p=(v:Vehicle)[:Drove]>(:Drive)[:Has]>(:State)[*0..]> (:State {stateId:1710})>(:State {stateId:552})> (:State {stateId:574})[*0..]>(:State) RETURN p
The same search in model variant 3 looks like this:
Match (v:Vehicle)[:Drove]>(:Drive)[:Has]> (c)>(:T {name: "1710_552"}), (c)>(:T {name: "552_574"}) with (v:Vehicle)[:Drove]>(:Drive)[:Has]>(c)>(:T) as p return distinct p
In both models it takes few milliseconds to query the data. Figure 7 shows the results of query 1. The query finds 4 paths and 6 drives.
In the second query from example 2, we search the database for all paths going through state and state . In Figure 8, we compare the result of query 2 in both model variants. In model variant 2, the query finds 8 simple paths and a cycle. In model variant 3, we have 9 paths and a cycle. The reason for the difference is, that in model variant 3, it is difficult to consider the order of the transit nodes. For this, it finds a path in which the state is visited before the state . Below is the possible query for variant 2:
MATCH (:State {stateId:1710})[c*]>(:State {stateId:574}) with (:Vehicle)>(:Drive)>(:State) [*{compHash: head(c).compHash}]>() as p RETURN p
The same search in model variant 3 looks like this:
Match (v:Vehicle)[:Drove]>(:Drive)[:Has]> (c)>(:T {start: "ST_Nav_DestInput_FTS_Result"}) ,(c)>(:T {end: "ST_Nav_LastDestinations"}) with (v:Vehicle)[:Drove]>(:Drive)[:Has]>(c)>(:T) as p return distinct p
In the third query, we are looking for non trivial cycles, which are visited more than one time by several users. Figure 9 shows one of the cycles with six nodes from the result list with 16 users. It shows that these users have difficulty to use a specific functionality, as they are repeating these particular steps several times.
Here is the Query 3 in Model variant 2:
Match p =(d:Drive)[h:Has]>(s:State)[:Circle*]>(:State) with id(d) as di , count(h) as NrVisit, s.compHash as CircleName, length(max(p))1 as CircleLen where NrVisit/CircleLen > 1 with CircleName, size(collect(di)) as NrDirves, avg(NrVisit/CircleLen) as NrVisits, CircleLen where NrDirves > 10 Return CircleName, NrDirves, NrVisits, CircleLen order by CircleLen desc limit 20
And here is the Query 3 in Model variant 3:
MATCH (n:Drive)[h:Has]>(c:Circles) with n, count(h) as ch, c where ch > 1 with c, size(collect(n.name)) as NrDirves, avg(ch) as NrVisits, size((:Circles {name: c.name})>(:T)) as CircleLen where NrDirves > 10 return c.name as CircleName, NrDirves, NrVisits, CircleLen order by CircleLen desc limit 20
In Query 4, we cluster the drives by their common components. It clusters from drives into clusters. There is a big cluster with elements which is a single component (a cycle). This cycle is a trivial cycle in which the application starts per default. In this clustering we are considering the exact common components. On the other hand, if we use only cycles for clustering we will have drives clustered into clusters. To cluster the remaining singleton clusters, we can use other scoring possibilities such as Jaccard distance, to compare the common neighborhood between drives. Here is the Query 4 in Model variant 2:
MATCH (n:Drive)[:Has]>(:State)[c]>(:State) with n, c.compHash as compHash order by compHash with n, collect(distinct compHash) as cluster with collect(n.name) as Drives, cluster where size(Drives) > 1 return cluster, size(Drives) as clusterSize order by size(Drives) desc
The same query in Model variant 3 looks like this:
MATCH (n:Drive)[:Has]>(c:Circles) with n, c.name as compHash order by compHash with n, collect(distinct compHash) as Cluster with collect(n.name) as Drives, Cluster where size(Drives) > 1 return Cluster, size(Drives) as clusterSize order by size(Drives) desc
One of the major challenges however remains the design of the proper injection pipeline for the components into the graph database. This comes from the fact that we have to avoid the duplicated components. That means at each insertion we have to check whether the component already exists in the database. We propose a hash indexing of the components in a lookup table to address this issue.
6 Discussion
In this work we have discussed the idea of remodeling the data representation and storage system, which can provide new possibilities for data analysis. In the case of sequence analysis, instead of traditional vectorization methods, we suggest a graph componentwise analysis. The concept behind it is derived from the fact that sequence itself is a traversal of a finite state automata. Based on this assumption, we introduce a new way of reviewing a sequence and consideration of loops. The main hypothesis is that the variation of components in a real use case converts. This assumption is very important because in a fully connected graph the number of possible simple paths and cycles increases exponentially with the number of nodes and edges. The number of simple paths in a graph with nodes for example can be approximated by the size of possible subsets of a element set, . Thus, we have to examine the hypothesis on a larger amount of data.
In general, due to the huge amount of data produced by the vehicles, the scalability is of great interest to us. In analysis of the model variants from section 4.2, we evaluated a specific implementation of Neo4j and highlighted its limitations. Further investigation of other graph databases and their comparative study is therefore necessary.
Last but not least, we introduce a platform for ad hoc analysis of customer click data. Most of the relational databases are equipped with dashboards and graphical visualization interfaces which make it easier for the enduser to use those systems. Graph databases have their own query languages which is not familiar to most endusers.Therefore, an evaluation of user friendly interfaces and visualization tools for graph databases is essential.
References
 [1] (2001) Clickstream clustering using weighted longest common subsequences. In Proceedings of the web mining workshop at the 1st SIAM conference on data mining, Vol. 143, pp. 144. Cited by: §1.

[2]
(2018)
Changing perspectives: using graph metrics to predict purchase probabilities
. Expert Systems with Applications 94, pp. 137–148. Cited by: §1, §1.  [3] (2010) Lists, decisions and graphs. pp. 164. Cited by: 4th item.
 [4] (2000) Integrating userperceived quality into web server design. Computer Networks 33 (16), pp. 1–16. Cited by: §1.
 [5] (2016) Networkthinking: graphs to analyze microbial complexity and evolution. Trends in Microbiology 24 (3), pp. 224–237. Cited by: §1.
 [6] (2019)(Website) External Links: Link Cited by: §4.3.
 [7] (2014) Improving web navigation usability by comparing actual and anticipated usage. IEEE transactions on humanmachine systems 45 (1), pp. 84–94. Cited by: §1.
 [8] (2004) Mining navigation patterns using a sequence alignment method. Knowledge and information systems 6 (2), pp. 150–163. Cited by: §1.
 [9] (2002) Separating the swarm: categorization methods for user sessions on the web. In Proceedings of the SIGCHI Conference on Human factors in Computing Systems, pp. 243–250. Cited by: §1, §4.1.
 [10] (2002) Using finite state automata for sequence mining. Vol. 24, Australian Computer Society, Inc.. Cited by: §1.
 [11] (2019) Sequence alignment on directed graphs. Journal of Computational Biology 26 (1), pp. 53–67. Cited by: §1.
 [12] (2005) Mining significant usage patterns from clickstream data. In International Workshop on Knowledge Discovery on the Web, pp. 1–17. Cited by: §1, §4.1.
 [13] (2006March 28) Method and system for clickpath funnel analysis. Google Patents. Note: US Patent 7,020,643 Cited by: §1, §4.1.
 [14] (2002) A bayesian treed model of online purchasing behavior using instore navigational clickstream. Revising for 2nd review at Journal of Marketing Research. Cited by: §1, §4.1.
 [15] (2004) Modeling online browsing and path analysis using clickstream data. Marketing science 23 (4), pp. 579–595. Cited by: §1, §4.1.
 [16] (2017) Genome graphs and the evolution of genome inference. Genome research 27 (5), pp. 665–676. Cited by: §1.
 [17] (2010) Insights from applying sequential pattern mining to ecommerce click stream data. In 2010 IEEE International Conference on Data Mining Workshops, pp. 967–975. Cited by: §1.
 [18] (2013) Graph databases. pp. 25. Cited by: §4.3, §4.
 [19] (2000) Web usage mining: discovery and applications of usage patterns from web data. Acm Sigkdd Explorations Newsletter 1 (2), pp. 12–23. Cited by: §1.
 [20] (2005) UBB mining: finding unexpected browsing behaviour in clickstream data to improve a web site’s design. In The 2005 IEEE/WIC/ACM International Conference on Web Intelligence (WI’05), pp. 179–185. Cited by: §1, §4.1.
 [21] (2013) You are how you click: clickstream analysis for sybil detection. In Presented as part of the 22nd USENIX Security Symposium (USENIX Security 13), pp. 241–256. Cited by: §1, §4.1.
 [22] (2017) Clickstream user behavior models. ACM Transactions on the Web (TWEB) 11 (4), pp. 21. Cited by: §1, §1, §4.3.2.
 [23] (2016) Unsupervised clickstream clustering for user behavior analysis. In Proceedings of the 2016 CHI Conference on Human Factors in Computing Systems, pp. 225–236. Cited by: §1, §1.
 [24] (2018) Network entropy for the sequence analysis of functional connectivity graphs of the brain. Entropy 20 (5), pp. 311. Cited by: §1.
Comments
There are no comments yet.