Exam objective 4.1 asks you to use transactions to group related events into a single logical unit. This is the key to answering trick questions about session identification and event correlation in the SPLK-1003 exam. Without mastering transactions, you will struggle to combine scattered log entries into meaningful interactions that businesses actually care about.
Jump to a section
A simple way to picture Transactions Basics
A restaurant kitchen receives a stream of tickets from the front of house. Each ticket is a single event: 'Table 7: steak, medium-rare' or 'Table 7: chocolate cake'. Alone, a ticket is just a data point. The chef needs to see the full meal for Table 7 to cook everything at the right time: starter, main, dessert, and the bill. This is a transaction.
The chef groups every ticket with the same table number and a close time stamp into one logical unit called a 'Table 7 experience'. He sets the boundaries: the first ticket opens the transaction, a gap of more than two minutes between tickets closes it, or a 'bill paid' ticket closes it. Within that group, he can calculate the total time Table 7 spent dining, the total bill, and the sequence of courses.
Without this grouping, the chef would see 20 separate tickets and have no idea which belonged to the same customer. He could not measure table turnaround time or spot that Table 7 ordered dessert before the main course. The transaction turns chaotic, disconnected data into a coherent story about one customer's visit. Exactly like Splunk's transaction command turns raw log events into a single, meaningful session.
A transaction in Splunk is a way to glue multiple separate log events together into one combined event. Think of your search results as a stream of individual events, each with its own timestamp and raw data. The transaction command picks certain events from this stream and bundles them based on rules you define.
The core idea is that many real-world activities generate multiple log entries. For example, a user logging into a website might produce separate events: one for the login attempt, one for the authentication success, one for loading the dashboard, and one for the first search query. Alone, each event is a loose fragment. As a transaction, they become a record of the user's session.
To use the transaction command, you write a search like this:
index=web_logs | transaction user_id maxspan=30m maxpause=5m
Let us break down each part. 'index=web_logs' is the data source. The pipe symbol '|' sends those events to the transaction command. Inside parentheses, you specify a field that identifies which events belong together — here, 'user_id'. Events with the same user_id are candidates for the same transaction. 'maxspan=30m' sets the maximum total duration of the transaction from first event to last event. Any group that spans longer than 30 minutes is discarded. 'maxpause=5m' sets the maximum allowed gap between consecutive events. If there is a gap of more than 5 minutes between events from the same user_id, the transaction is closed, and a new one starts for that user_id.
You can also use the 'startswith' and 'endswith' options to define clear boundaries. For example:
... | transaction user_id startswith="login" endswith="logout"
This creates a transaction that only includes events from the first 'login' event to the last 'logout' event for each user_id. This is very precise and avoids cutting a session short.
Why does this exist? Before transactions, you had to correlate events manually using stats, eventstats, or join commands — which were messy and slow. Transactions are purpose-built for this exact task. They replace the need to write complex time-based joins manually. They also replace searching for patterns across multiple raw events, which is tedious and error-prone.
There are three key options you must know for SPLK-1003:
'maxspan' sets the maximum time from the first event in the transaction to the last event in the entire transaction. Use it when you know a session or process never exceeds a known duration (e.g., a credit card payment cannot take more than 60 seconds).
'maxpause' sets the maximum time gap between any two consecutive events inside the transaction. Use it when events may happen irregularly but should still belong to the same session (e.g., a user browsing a website, clicking at unpredictable intervals).
'startswith' and 'endswith' define event patterns that mark the beginning and end of a transaction. Use them when your data has clear start and stop markers (e.g., a 'Session Start' log and a 'Session End' log).
'startswith' and 'endswith' take a string or a regular expression. They match against the raw event text or against a specific field if you use the 'fields' option. If you do not provide 'endswith', the transaction closes when 'maxspan' or 'maxpause' is exceeded. If you do not provide 'startswith', any event can start a new transaction.
Transactions produce a new combined event that contains all the raw text from the constituent events, plus new fields like 'duration' (the time between the first and last event) and 'eventcount' (how many events were bundled). You can then use stats functions on these new fields to calculate average session length, count of transactions, and so on.
There is a performance consideration: the transaction command uses a lot of memory because it holds open groups in memory until they close. If you have many events or long maxspan values, this can slow down your search. Splunk recommends using more specific search filters first to reduce the event volume before using transaction. You can also use the 'mv' (multivalue) functions and 'eventstats' as lighter alternatives in some cases. But for the exam, transaction is the tool you use when you need to bundle events into a single searchable unit.
Identify Events to Group
First, understand what real-world activity you want to capture. Look for a field that appears in all related events, such as user_id, IP address, session_id, or order_id. This field becomes the grouping key. Without a clear grouping field, transactions cannot work.
Set the Time Boundaries
Decide how long the activity can last and how much gap is allowed between events. Choose maxspan if the entire process has a known maximum duration (e.g., a checkout process that never takes longer than 30 minutes). Choose maxpause if events can be sporadic but still belong to the same session (e.g., user clicks on a website with pauses of up to 10 minutes). Set both for tight control.
Define Start and End Markers (Optional)
If your data has clear start and end events (like 'login_attempt' and 'logout'), use startswith and endswith. These create precise transaction boundaries and prevent events from being cut off prematurely. If your data lacks clear markers, skip these options and rely on time boundaries.
Run the Transaction Command
Write the search: pipe your filtered events into the transaction command, followed by the grouping field and options. Example: `index=web | transaction user_id maxspan=1h maxpause=5m`. Let Splunk process the events. It holds groups in memory until they close, then returns the combined events.
Analyse the Results
After transaction, you get new fields: 'duration' (total seconds), 'eventcount' (number of events), and multivalue versions of original fields. Use stats to calculate averages or counts. Use where to filter by eventcount or duration. Use mvfind to check if a specific value exists inside a multivalue field. This step turns raw transactions into actionable metrics.
An IT professional at an e-commerce company needs to analyse customer purchase journeys. The website logs events every time a user performs an action: page view, add to cart, remove from cart, checkout click, payment confirmation, and order success. Each event is a separate log line with a timestamp, user_id, and action_type. The operations team wants to answer two questions: what is the average time from first page visit to purchase, and how many users abandon their cart before completing payment?
Step one: the analyst writes a search that filters only events from the e-commerce application index. She uses index=ecommerce_web | transaction user_id maxspan=2h startswith="page_view" endswith="order_success". This groups every user's actions into a single transaction, starting when they first view a page and ending only if they successfully order.
Step two: she looks at the results. Each transaction now shows all the raw events from that user's session. The transaction command created a new field called 'duration' that shows exactly how long each session lasted, from first page view to order success.
Step three: she uses stats to find the average duration: | stats avg(duration) as avg_session_duration. This gives her the answer to the first question — the average time to purchase is 18 minutes.
Step four: to find cart abandonment, she modifies the search. She removes the 'endswith' option so any user whose session has a 'checkout_click' event but no 'order_success' event will still show up as an open session that eventually closes via maxpause or maxspan. She then uses | where eventcount>5 AND NOT mvfind(action_type, "order_success") to find users who performed multiple actions but never completed the order. This reveals a 22 percent abandonment rate.
The IT professional then reports these metrics to the marketing team. The marketing team uses the average session duration data to decide when to send follow-up emails. The cart abandonment data triggers a redesign of the checkout page. All of this insight comes from transactions — a single command that turns scattered log lines into coherent user stories.
In a security context, a SOC analyst uses transactions to group events like failed login attempts followed by a successful login from the same IP address. The transaction might look like: index=security_logs | transaction src_ip maxspan=15m startswith="failed_login" endswith="successful_login". This helps them spot brute-force attacks: a single transaction containing ten failed logins then one success is a strong indicator of a compromised account.
Network engineers use transactions to trace a packet's journey across multiple routers. Each router produces an event with a unique flow ID. The transaction command groups all events with the same flow ID, showing the entire path and the time spent at each hop. This replaces the need to manually correlate timestamps across different devices.
The SPLK-1003 exam tests your understanding of the transaction command in several specific ways. First, they will give you a scenario and ask which option to use: maxspan, maxpause, startswith, or endswith. The trap is that beginners confuse maxspan and maxpause. Remember: maxspan is the total duration from first to last event in the entire transaction. Maxpause is the gap between any two consecutive events inside the transaction. A correct answer pattern: if the scenario mentions 'no more than 5 seconds between clicks', that is maxpause. If it mentions 'the whole process cannot take longer than 2 hours', that is maxspan.
Second, the exam tests what happens when no startswith or endswith are provided. The default behaviour is: any event can start a transaction, and transactions close when maxspan is exceeded or maxpause is exceeded. If you do not provide these options, a transaction never forms because there is no boundary — you must specify at least one of maxspan or maxpause. The exam uses this to trap candidates who assume defaults will create infinite groups.
Third, they test the concept of eventcount. After a transaction runs, each combined event gets an 'eventcount' field that shows how many original events were bundled. The exam may ask you to filter transactions with more than a certain number of events. For example, 'find transactions with more than 5 events' is answered with | where eventcount > 5.
Fourth, they test the use of the 'mv' fields. After transaction, fields that had different values across events become multivalued fields. So if you have three events with different 'action_type' values, the resulting transaction has a field called 'action_type' that contains all three values as a multivalued list. The exam may ask you to search for transactions that contain a specific action, such as 'login'. This requires using 'mvfind' or 'mvappend' commands.
Fifth, there are performance traps. The exam may present a scenario where the search is slow and ask how to improve it. The correct answer is to narrow the search before the transaction command — for example, by adding a more specific index or sourcetype filter, or reducing the maxspan. They may also test that transaction uses memory and too long a maxspan causes poor performance.
Key exam topics to memorise:
Differences between maxspan and maxpause: maxspan limits total transaction length, maxpause limits gaps between events.
Default behaviour without startswith or endswith: any event can start, transaction closes via maxspan or maxpause.
Use of 'fields' option: you can specify which fields to carry forward. By default, all fields are kept. Using 'fields' limits memory usage.
The 'mv' prefix for multivalue fields: after transaction, access first value with 'mvindex(field_name, 0)'.
The 'duration' field: it is the difference in seconds between the timestamps of the first and last events in the transaction.
The 'eventcount' field: it is the number of events bundled into the transaction.
Exam question types include multiple-choice, drag-and-drop to match options to descriptions, and scenario-based questions where you must choose the correct transaction syntax. The trap patterns always involve confusing maxspan with maxpause, forgetting to include a field to group by, or assuming startswith and endswith are required when they are not.
The transaction command bundles multiple log events into one combined event based on a shared field like user_id or session_id.
Use maxspan to set the maximum total duration from the first event to the last event in the transaction.
Use maxpause to set the maximum allowed gap between any two consecutive events inside the transaction.
startswith and endswith are optional options that mark the beginning and end of a transaction with specific event patterns.
After a transaction, the resulting event has a duration field (in seconds) and an eventcount field (number of bundled events).
Fields with different values across grouped events become multivalued fields, accessible via mvindex, mvfind, or mvcount.
These come up on the exam all the time. Here's how to tell them apart.
maxspan
Limits total duration from first event to last event in the whole transaction
Use when the entire process has a known maximum length (e.g., a checkout cannot exceed 30 minutes)
If exceeded, the entire transaction is discarded
maxpause
Limits the gap between any two consecutive events inside the transaction
Use when events can be sporadic but belong to the same session (e.g., user clicks with pauses up to 10 minutes)
If exceeded, the transaction closes and a new one starts for the same grouping field
startswith/endswith
Requires specific event patterns to mark start and end
Precise and prevents premature closing of transactions
Best for data with clear start and stop markers (e.g., login/logout events)
Time-based boundaries (maxspan/maxpause)
No specific event patterns needed
Transactions close when time limits are reached, potentially cutting a session short
Best for data without explicit start/end markers or when exact boundaries are unknown
transaction command
Produces a combined event with all raw text from original events
Creates multivalue fields for fields with different values
Memory-intensive and slower for large datasets
stats command
Produces a table of aggregated values, not combined events
Fields remain singular; uses functions like count, sum, avg
Typically faster and more memory-efficient
Mistake
You must always provide both startswith and endswith options for a transaction to work.
Correct
You can omit both startswith and endswith. The transaction will then close based on maxspan or maxpause boundaries. These options are optional, though often useful for precise control.
Beginners see examples that always use startswith/endswith and assume they are mandatory. The exam tests this directly by presenting a scenario where only maxspan is used.
Mistake
maxpause limits the total time from the first event to the last event in the transaction.
Correct
maxpause limits the maximum gap between any two consecutive events inside the transaction. maxspan limits the total time from first to last event. They serve different purposes.
Both terms sound similar and both involve time limits. Beginners mix them up because they both relate to 'time allowed'. The exam loves this confusion.
Mistake
After a transaction, all fields from the original events remain singular, and you can search them normally.
Correct
After a transaction, any field that had different values across the grouped events becomes a multivalued field. You must use functions like mvindex or mvfind to access individual values.
Beginners expect fields to stay simple like in stats. The multivalue behaviour is unintuitive and only shows up when you actually look at the results. The exam tests this by asking how to find a specific value in a transaction.
Mistake
You can use the transaction command without specifying a field to group events by (like user_id or session_id).
Correct
You must specify at least one field for Splunk to group events. Without a grouping field, Splunk does not know which events belong together and will not form any transactions.
The syntax looks simple, and beginners think the command automatically detects groups. They forget that the grouping field is required, and the exam presents a search without it to see if you notice.
Mistake
Transaction is the fastest way to group related events.
Correct
Transaction is memory-intensive and slower than alternatives like stats, eventstats, or streamstats. Use it only when you need the combined event view. For simple aggregations, prefer other commands.
The command sounds official and powerful, so beginners assume it is optimal. In reality, Splunk documentation warns about its performance cost, and the exam tests awareness of this.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
maxspan limits the total time from the first event to the last event in the entire transaction. maxpause limits the maximum gap between any two consecutive events inside the transaction. They control different aspects of the transaction's time boundary.
Yes, you can. If you omit startswith and endswith, the transaction will close based on the maxspan or maxpause boundaries you set. This is common when your data does not have clear start and end markers.
This usually happens because you did not specify a grouping field (like user_id or session_id), or the events you selected do not share the same value in that field. Also, check that your maxspan or maxpause values are not too restrictive for the data.
A transaction produces new fields including 'duration' (the time difference in seconds between the first and last event in the transaction) and 'eventcount' (the number of original events bundled). Original fields become multivalued if they have different values across the grouped events.
You use the mvindex function to get a specific position (e.g., mvindex(action_type, 0) for the first value), or mvfind to search for a value (e.g., mvfind(action_type, "purchase")). You can also use mvcount to count the number of values.
Not always. Transaction is memory-intensive and can be slow for large data volumes. For simple tasks like counting events per user or calculating averages, consider stats or eventstats first. Use transaction only when you need the full, combined event view with all raw text preserved.
You've finished Transactions Basics. Continue through the SPLK-1003 study guide to build a complete picture of the exam.
Done with this chapter?