Collect browser and behavioral signals and carry them with the interactions Darwinium protects. For a website integrated at the CDN, the profiling package can inject collection code into HTML responses without adding the script separately to each application page.
Choose one delivery approach for a page. Installing several alternatives and injecting them together can duplicate collection or request hooks.
Choose the delivery package
| Package | How it fits your site | Main snippet file |
|---|---|---|
| Darwinium profiling and biometrics | Inject profiling into a proxied HTML response | dwn_profiling.snippet |
| Darwinium profiling (Tag only – no proxy) | Serve a profiling resource used by your application-side tag integration | dwn_profiling_tag.snippet |
| Darwinium profiling (split delivery) | Inject a small bootstrap and serve a separate deferred bundle | dwn_profiling_split.snippet |
Start with Insert JavaScript profiling at the edge for the CDN deployment design. The steps below explain the Marketplace configuration within that design.
Example: profile a login page using fetch
Install Darwinium profiling and biometrics and keep dwn_profiling.snippet with its supporting fpjs/dwn_profiling.js file. Import the snippet into your journey and add Inject darwinium profiling to the login page's HTML response mapping.
If the application submits login through fetch('/api/login', …), configure:
| Setting | Example value | Why |
|---|---|---|
| Application HTTP Requests | fetch |
Hooks the request mechanism the application uses |
| Fetch/xhr URL allow-list | /api/login |
Adds profiling to the protected submission |
| Fetch/xhr URL regex | Empty | Uses the allow-list configuration |
| Form Post CSS Selector | none |
This example sends through fetch rather than an HTML form |
| Keyboard, mouse and touch biometrics | Enable the collection needed for the flow | Captures the corresponding interactions before submission |
The hook carries profiling in the dwn-profiling request header. Use both when the application uses both fetch and XMLHttpRequest. With current templates, the allow-list accepts a URL glob or a list; a host-qualified entry such as https://shop.example.com/api/** restricts it to that host and path family. A configured regex overrides the allow-list.
For a normal HTML form submission instead, select none for Application HTTP Requests, set the fetch/xhr allow-list to none, and use a form selector such as form#login. The package adds profiling as a form field for matching submissions.
Identify an input for keyboard biometrics
Add Enable Keyboard Biometrics On Input Field (key_bm_map_delay) to the page and configure its field selector, for example input#email, and biometrics context, for example EMAIL. Use the selector that matches your rendered page. This lets you distinguish the field's interaction data in the selected context.
Prefer this template over the one marked deprecated. Keep optional geolocation and device-sensor settings deliberate; browser permissions and the availability of those signals differ from ordinary mouse or keyboard collection.
Tag-only delivery
Install the tag-only package and import dwn_profiling_tag.snippet. Add Tag Profiling Step, which creates a step rather than an HTML operation. Configure its host, listen URL (default /dwn_profiling.js) and namespace.
Your application must request that resource and submit profiling through its JavaScript tag integration. Installing the serving step does not add a tag to application pages. Keep the downloaded JavaScript and WebAssembly assets from the same package together.
Split delivery
Add the bootstrap injection to the page and the dwn_profiling_deferred_step template as a serving step. Set the same deferred URL on both, such as /dwn.js, and configure the serving step's host.
The boot load mode starts the deferred bundle after window load; script emits the asynchronous script tag directly. The ready deadline controls how long a matching request waits for the deferred bundle before proceeding untouched. Review that tradeoff for fast submissions and slow connections rather than changing the deadline only to maximize collection.
The serving step provides caching settings for the static bundle. The separate Speedbump template is optional; profiling installation alone does not configure a bot-mitigation decision.
Verify collection at the protected submission
Deploy to a test target, load the page and interact with the intended fields before submitting. Check the script resources in the browser, the profiling header or form field on the protected request, and the resulting profiling attributes in Investigations.
Test a non-matching URL to confirm the allow-list's boundaries, a single-page-app navigation, and a quick submission on a slow connection. Missing profiling on one event needs investigation of loading, matching and timing before it is interpreted as a fraud signal. Continue with Detection model templates when collection is working.