Preparing the details that protect your business.
Preparing the details that protect your business.
A specific account of how KOMERRA uses browser storage for security, sign-in, preferences, analytics, and privacy-controlled experience monitoring-without an invented advertising stack.
This Cookie and Browser Storage Policy explains how KOMERRA Technologies Limited uses cookies, local storage, session storage, and similar browser technologies on KOMERRA websites and applications.
It covers strictly necessary storage, optional preferences, analytics, experience monitoring, consent records, provider-controlled surfaces, retention, and the controls available to visitors and Account users.
This Policy should be read together with the Privacy Policy, Security & Trust page, Data Retention Policy, and Subprocessors page.
KOMERRA is operated by KOMERRA Technologies Limited, a company registered in the Federal Republic of Nigeria with registration number 9681120.
Questions about cookies, browser storage, analytics, consent, or experience monitoring may be sent to support@komerra.app.
Use “Cookie and Privacy Question” in the subject.
A cookie is a small value that a website asks a browser to store and return with relevant requests.
Local storage allows a website to retain limited information in the browser beyond the current tab or session.
Session storage ordinarily lasts for the current browser tab or session.
Similar technologies may include software development kits, pixels, local identifiers, embedded scripts, tags, and other tools that store information or recognize a browser or device.
This Policy applies according to what the technology does, not merely what it is called.
Strictly necessary storage is enabled where it is required to provide, secure, stabilize, or make the website accessible.
Optional preferences, analytics, and experience monitoring remain disabled until the visitor makes the relevant choice.
Each optional category can be accepted or rejected separately through Cookie Settings.
Refusing optional storage does not prevent ordinary access to public pages or the core authenticated service, although a particular optional convenience may remain unavailable.
KOMERRA does not treat silence, inactivity, scrolling, continued browsing, or a pre-selected control as consent to optional processing.
Strictly necessary storage supports functions that cannot reasonably be provided in the same way without it.
The first-party cookie named komerra_cookie_consent records the choices made through the KOMERRA consent banner or Cookie Settings.
It records the consent-policy version, whether each optional category was enabled, the date of the choice, and whether the choice was made through the banner or settings interface.
It does not contain a password, authentication token, payment credential, private Business Content, or advertising profile.
The current implementation retains this browser-level choice for up to 180 days unless it is deleted earlier, replaced by a newer choice, or invalidated because the consent model changes materially.
Authenticated use may require first-party cookies that establish, maintain, refresh, or protect an Account session.
Authentication secrets should be stored in secure, HTTP-only cookies where appropriate so ordinary browser scripts cannot read them.
Production authentication cookies should use secure transport and appropriate SameSite and expiry controls.
A browser-visible sign-in indicator may be used for interface presentation, but it must not be trusted as proof of identity, role, Workspace authority, or permission.
Server-side authorization remains responsible for deciding what the user may access or change.
Short-lived cookies or browser values may retain a challenge identifier, expiry, masked destination hint, anti-forgery state, safe return path, or temporary marker needed to complete an authentication, verification, recovery, or security workflow.
These values should not contain the user’s password or the one-time code itself.
Temporary state should expire or be removed when the workflow ends or is abandoned.
With permission, KOMERRA may remember optional interface and experience choices that are not strictly required for core operation.
With analytics permission, KOMERRA may measure aggregated use of public pages and product features to understand performance, adoption, navigation, errors, and whether a feature is useful.
Possible information may include page or feature events, approximate time, browser and device information, referral information, campaign information, coarse location derived from network information, and privacy-limited identifiers.
Analytics should not receive passwords, authentication secrets, private message contents, protected files, full payment credentials, or unnecessary Business Content.
KOMERRA does not currently use the analytics category for behavioural advertising or the sale of advertising profiles.
With experience-monitoring permission, KOMERRA may use privacy-controlled diagnostics to understand serious usability failures, broken interactions, navigation problems, repeated clicks, performance issues, and errors experienced by users.
This may include masked session replay, interface states, clicks, scrolling, navigation, device information, technical errors, and limited diagnostic context.
Passwords, authentication codes, payment credentials, private keys, government identifiers, protected files, sensitive form fields, and designated sensitive screens should be blocked, excluded, or masked.
Experience monitoring must not be used as a hidden substitute for advertising, unrestricted employee monitoring, or collection of complete private Workspace content.
KOMERRA may create limited technical, operational, abuse-prevention, fraud, and security records where they are necessary to keep the service working, investigate a failure, protect Accounts, enforce permissions, or meet a legal obligation.
These necessary records are distinct from optional analytics and session replay.
Classifying an event as essential does not permit KOMERRA to reuse it for unrelated tracking, behavioural advertising, or unrestricted product analytics.
Essential diagnostic processing should remain proportionate, access controlled, and subject to the applicable retention rules.
KOMERRA may use local or session storage for the consent choice, temporary navigation state, limited onboarding progress, essential interface continuity, and optional preferences selected by the user.
Session storage may remember whether a temporary introduction has played or preserve limited state while the user completes a workflow.
Browser storage must not be treated as a secure location for passwords, refresh tokens, private keys, one-time codes, or provider secrets.
Clearing browser storage may reset local preferences and temporary progress without deleting records retained within the KOMERRA Account or Workspace.
KOMERRA does not currently describe or activate a category for third-party behavioural advertising cookies.
The absence of advertising cookies does not mean that no browser technology is used; strictly necessary, preference, analytics, and experience categories remain governed by this Policy.
If behavioural advertising or materially different tracking is introduced, it must not be silently placed inside an existing category.
The consent version, banner, provider register, and this Policy should be updated before that processing begins.
A payment provider, messaging platform, embedded service, support provider, or other connected service may set cookies on its own domain when the user deliberately opens or uses that service.
The provider’s own cookie and privacy terms may apply to its independent processing.
KOMERRA should not rely on a third-party browser cookie as the sole proof that a payment succeeded.
Payment and other high-impact provider outcomes should be verified through trusted server-side processes.
A choice made through the public consent banner ordinarily applies to the browser and device in which it was stored.
The choice may not automatically follow the user to another browser, private-browsing session, device, cleared browser profile, or unrelated domain.
An authenticated Account preference may be synchronized in the future only where the operation is implemented transparently and does not cause optional processing to start before the applicable choice is known.
Visitors and users can open Cookie Settings from the persistent control shown on the website or from an appropriate footer or Settings link.
Optional categories can be enabled or disabled separately.
Withdrawal applies to future processing under the affected consent category.
KOMERRA should stop loading the relevant optional provider after withdrawal and invoke the provider’s available opt-out or reset controls where necessary.
Withdrawal does not automatically erase lawful records already needed for security, legal obligations, dispute handling, or another valid purpose.
Browsers allow users to inspect, block, or delete cookies and local storage.
Blocking strictly necessary cookies may prevent sign-in, session continuity, security checks, or other authenticated functions from working correctly.
Deleting the consent cookie may cause the banner to appear again because the website can no longer remember the earlier choice.
Deleting browser storage does not automatically delete the user’s Account, Workspace, orders, customers, documents, payment records, or other server-held information.
The consent choice is currently designed to last for up to 180 days in the browser.
Authentication, temporary workflow, provider, analytics, monitoring, security, and diagnostic records may use different retention periods according to their purpose and applicable configuration.
Optional providers should not retain information longer than the period approved for the relevant purpose.
The applicable Data Retention Policy and internal retention register should identify material provider-side retention and deletion requirements.
KOMERRA is designed primarily as a business-management service rather than a consumer service directed at children.
Optional consent should not be relied upon for processing a child’s personal data without addressing the applicable age, authorization, information, fairness, and verification requirements.
The interface should use language that is understandable to its intended audience and should not pressure a vulnerable person into accepting optional tracking.
KOMERRA may update this Policy when its authentication model, browser storage, providers, analytics, experience monitoring, product features, legal requirements, or consent controls change.
A material new optional purpose should trigger an updated consent version so an earlier choice is not silently stretched to cover different processing.
Strictly technical changes that do not materially change the purpose or privacy effect may not require a new consent request.
The production cookie and storage inventory should be reviewed whenever a new script, provider, SDK, tag, embedded service, or browser identifier is introduced.
Send cookie, consent, analytics, and experience-monitoring questions to support@komerra.app.
Use “Cookie and Privacy Question” in the subject.
Identify the browser, device, affected page, approximate date, and the choice or behaviour you observed.
Do not send passwords, one-time codes, recovery codes, private keys, bank PINs, or card security codes.
Ask a cookie or consent question
Contact support@komerra.app or use the contact form. Privacy and security reports are routed to the responsible team.