WebAgent Setting
IMQA WebAgent enables actions with different options for different services.
1. Required Settings
Enable IMQA
IMQA WebAgent requires inserting the script into the top of your html in the <head>. Must include the required options below for it to work properly.
imqaAgentUse
boolean
true
true : Enable IMQA WebAgent.
false : Disable IMQA WebAgent.
projectKey
string
“User project key”
Enter the WPM project key created by IMQA.
The script with the required settings only is as follows:
Setting up Cross-Domain
You can set up cross-domains in addition to the main domain to be analyzed by IMQA. It allows you to specify which sources are allowed when subdomains (such as m.imqa.io) are configured separately, or when access to cross-origin resource sharing (CORS) is required.
① Click […] in the IMQA WPM project to go to the project management menu.
② Click [Cross-domain] settings.
③ The main domain URL entered when creating the default project is set. Enter the sources to allow access to subdomain or cross-origin resource sharing, depending on your website configuration.
Example of Allowed Domains
Designate a list of domains to allow access to the Allowed Domain URL. (e.g., http://localhost:8080)
You can enter the URL in one line; it consists of protocol and port number, it is case-sensitive, and it cannot contain the * character.
④ Enter the list of allowed domains and click [Save].
⑤ Data will be collected from the list of allowed domains in real time, and you can view the collected data in IMQA.
By default, IMQA WebAgent supports data collection only from units that are critical to the user’s web browser application configuration and collects data only from allowed domains for license protection by installation code cloning, for example. If you want to collect performance data from domains other than the main domain URL, you need to set up a list of allowed domains through Setting up Cross-Domain.
Configure URL Patterns
You can find patterns in website URLs, replace them with the desired form, and collect them with IMQA. This feature lets you replace numbers and identifiers (such as referrer IDs, user IDs, and search terms) in URLs and group similar pages into meaningful aggregate units.
By default, IMQA WPM collects raw URL data that users access. For pages where URLs are likely to be fragmented by multiple identifiers and search terms as users navigate your website, we recommend defining meaningful aggregate/analysis units through Configure URL Patterns.
❶ URL Pattern Enter the pattern you want to replace in the path or query parameters of the website URL. You can enter path and query parameter units. URL patterns with the highest priority are replaced first. Query parameters should be entered as “key=value."
1. Insert a variable {group} into the units you want to enclose in the path or query parameters depending on your website URL configuration.
2. Insert a variable {value} into the units you want to unpack in the path or query parameters depending on your website URL configuration.
3. Enter the URL pattern and click the [+] icon.
Exemplified Configuration of URL Patterns (1)
“I want to bundle numbers following the ‘products’ path, which is the URL jumping to the product details, into a single page for aggregation/analysis. No need to be specific about the query parameters.”
1. Enter the URL pattern you want to apply to a specific “path,” including the variable {group}. 2. Replace the URLs collected from the time of setup with your desired form, so that IMQA can check them on a “page” basis.
Exemplified Configuration of URL Patterns (2)
“I want to distinguish the types of incoming traffic to the main page. The external incoming IDs ‘fbclid’, ‘NaPm’, and ‘gclid’ added to the URL query parameters should be recognized, but no need to show values in detail.”
1. Enter the URL pattern you want to apply to a specific “path” and “query parameter,” including the variable {group}.
2. Replace the URLs collected from the time of setup with your desired form, so that IMQA can check them on a “page” basis.
Exemplified Configuration of URL Patterns (3)
“I want to distinguish between categories on the best products list page. Please distinguish between the category ID ‘category_id’ and the value added to the URL query parameter of the ‘best’ path, and the rest of the query parameters don’t need to be so granular.”
1. Enter the URL pattern you want to apply to a specific “path” and “query parameter,” including the variable {value}.
2. Replace the URLs collected from the time of setup with your desired form, so that IMQA can check them on a “page” basis.
❷ Priority Indicates the order in which URL patterns are applied. URL patterns with the highest priority are applied first, but you can change the order.
Example of Priority Setup
“A pattern of enclosing numbers following the ‘products’ path, the URL jumping to product details, is being applied. I want to distinguish further between the types of accesses: external ID ‘fbclid’ and internal ID ‘flow’ going from the main to product details.”
1. URL patterns that apply to “paths” with higher priority are applied first. 2. The URL pattern applied to specific “path” and “query parameter” is adjusted to have higher priority.
3. The URL pattern applied to the “query parameter” will be replaced with the desired form initially.
❸ URL Patterns Displays a list of all URL patterns set up in the project.
❹ Changing Priority You can adjust the order in which URL patterns are applied by dragging the mouse.
❺ Delete Deletes the URL pattern you added. The deleted URL pattern is no longer applied
Click [Save] when you are done setting the URL patterns and priority to apply. Replaces the URLs collected from the time of setup with your desired form, so that IMQA can check them on a “page” basis.
2. [WPM] SPA-only Options
There are no events for page shifts because data is collected based on a single index.html in SPA. You can set SPA-only options to collect up to a certain time based on when the path changes. In SPA, a specific DOM is replaced when the path changes, so if you set this specific DOM as the target in the Agent option, you can collect page load times in SPA as normal.
SPACollectInitTime
number
3000
- Default: 3000 (3 seconds) - Set the performance data collection interval in milliseconds (ms) in SPA.
- When the path changes, data is collected for the set collection time.
SPARootDom
string
“#app”
- Set a DOM targeted by the CSS selector style
- Detect DOM changes based on the targeted DOM.
(ID : #app, Class : .app)
- If you set duplicate selectors as a target, data will not be collected properly.
The script with the required settings and SPA-only options is shown below.
3. [WPM] Retention Time for Behavioral Analytics
You can set the retention time of user behavior sessions that will be referred to by IMQA behavior analytics. The session lasts for a default 30 minutes and ends when the user has not moved a page in 30 minutes.
If, on average, users spend a long time on your website without page navigation, such as on a content-driven website, you can set the retention time such that the session does not end.
browserTxIdIntervalTime
number
800000
- Default: 1800000 (30 minutes) - Set the session retention time in ms (milliseconds).
- Set the retention time for ID value to keep tracking the user’s course of action.
The script with the required settings and Retention Time for Behavioral Analytics is shown below.
4. [WPM] Measuring Script Execution Time
You can track a time spent on a specific piece of logic in JavaScript in the IMQA timeline. mark and measure, two standard performance entries, for easy tracking. Please define the text inside each mark and measure as unique, non-duplicate text.
Note that when applied to the framework core, the tracked code may increase abnormally and cause memory leaks.
① Define Performance.mark and measure at the top and bottom of the script where you want to measure the execution time.
② You can see the scripts you marked in a popup scripting section for “Page Load Time Analytics,” and the execution times of those scripts are displayed.
You can also measure the execution time of a specific script as shown below.
5. [WCrash] Custom Web Crash
IMQA WebAgent lets you collect custom errors by specifying the desired error messages for detailed web error analytics.
Create Custom Errors
IMQA WCrash detects and collects user-defined errors.
Different errors but of the same error type are recognized as the same error, which can lead to error accumulation.
Custom Error Messages
You can change the default error messages to any error messages you want and collect them by WebAgent. We recommend specifying several error messages for detailed web error analytics.
If you specify error messages, even errors of the same type will be collected as different errors.
Web Crash Analytics
You can view web crashes with detailed information in the IMQA WCrash service as shown below.
❶ Caught Error Instance Type Displays the name of the caught error instance of the error if it is generated on a web page.
Error
User-set error type.
EvalError
Error raised by eval().
RangeError
Error generated when a variable is out of a valid range.
ReferenceError
Error generated when an invalid reference is made.
SyntaxError
Error generated when invalid syntax is present.
TypeError
Error generated when the data type of data is not valid.
URIError
Error generated when an improper parameter is passed to the encodeURI() or decodeURI() function.
AggregateError
Wrapping multiple errors into a single error.
❷ Custom Error Message Displays a user-specified message when a specific error-type error is generated.
Last updated