Purpose of global configuration
Global configuration defines how the SDK behaves after initialization. Use it to set app-wide defaults for logging, request delivery cadence, auto-tracking behavior, crash tracking, batch support, and selected identity-related features.
When to configure it
Apply global configuration before calling init(...). This keeps startup behavior predictable and avoids scattering SDK behavior across the app.
How to think about this step
This page is about startup-level defaults, not about later runtime operations. Start with the smallest stable configuration that fits your app, then add only the options your implementation really needs.
Minimal example
val configuration = WebtrekkConfiguration.Builder(
listOf("1111111111111111111111111"),
"https://your-trackdomain.com"
).build()
Webtrekk.getInstance().init(this, configuration)WebtrekkConfiguration configuration = new WebtrekkConfiguration.Builder(
Arrays.asList("1111111111111111111111111"),
"https://your-trackdomain.com"
).build();
Webtrekk.getInstance().init(this, configuration);Common extended example
val configuration = WebtrekkConfiguration.Builder(
listOf("1111111111111111111111111"),
"https://your-trackdomain.com"
)
.logLevel(Logger.Level.BASIC)
.requestsInterval(interval = 15)
.enableCrashTracking()
.build()
Webtrekk.getInstance().init(this, configuration)WebtrekkConfiguration configuration = new WebtrekkConfiguration.Builder(
Arrays.asList("1111111111111111111111111"),
"https://your-trackdomain.com"
)
.logLevel(Logger.Level.BASIC)
.requestsInterval(15)
.enableCrashTracking()
.build();
Webtrekk.getInstance().init(this, configuration);Recommended first-pass decisions
Logging: use development-friendly logging while integrating, then reduce it for production if needed
Request interval: keep the default supported cadence unless you have a concrete reason to change it
Auto-tracking: only disable it if your implementation needs explicit control
Crash tracking: decide deliberately whether crash data belongs in your analytics setup
Identity and privacy: enable migration, user matching, or custom everID handling only when your use case explicitly requires them
What belongs here and what does not
This page should cover app-wide startup configuration. Runtime operations such as opt-out, changing track IDs and domains during runtime, forcing immediate send, or reading the active configuration belong in separate runtime-focused documentation.
What this step should achieve
After this step, your SDK setup should be stable enough that you can move into tracking implementation without revisiting the startup flow.
Next step
Continue with the tracking implementation that fits your app, such as Automatic Tracking, Object Oriented Tracking, or Query Parameter Tracking.