moloads
Legal

Privacy Policy

This explains what we collect, why we collect it, how long we keep it and how to get it removed. It is written against what the software actually does, not against a template.

Last updated 19 August 2026
Operator Brandmongo, operating Moloads at moloads.com
Address Gurugram, Haryana 122001, India
Privacy contact info@brandmongo.com · +91 70275 88785
01

Two different relationships

Nearly everything confusing about advertising privacy comes from collapsing two separate things into one policy, so we keep them apart.

  • You, dealing with us. You visit this site, request access, or hold a console account. For this data we are the controller and this policy is the whole answer.
  • People whose ad impressions our customers bid on. When a customer runs campaigns through the platform, they decide what to target, what to measure and how long to keep it. For that data the customer is the controller and we are their processor, acting on their instructions. If you are an end user asking why you saw an ad, the advertiser who ran it is the party who can answer, and section 10 explains how to reach us if you cannot identify them.
02

Visiting this website

This site sets no cookies and runs no analytics. There is no tracking pixel, no advertising tag and no session recording. Our content security policy refuses third-party scripts outright — including an analytics beacon our CDN injects by default, which the browser blocks before it can run, so it never loads and never collects anything. The typefaces are served from our own domain rather than a font CDN, so loading a page does not tell anyone else that you did.

Our servers keep ordinary web logs — the request path, the response status, timing and the connecting IP address — which we use to keep the service running and to investigate abuse. The sign-in page and the console store two values in your browser's local storage once you sign in, described in section 6.

03

Requesting access

Accounts are not self-serve, so the request form is the only way in. A person reads every submission. These are the exact fields it stores:

FieldRequiredWhy
NameYesTo address you, and to set up the account
EmailYesTo send the decision and, if approved, your credentials
Company, websiteNoTo review the request
Monthly spend, verticals, traffic sourcesNoTo judge whether the platform fits what you run
MessageNoWhatever you choose to tell us
IP address, browser user-agentCapturedRate limiting and abuse prevention on a public form

The form carries a hidden field that real people never fill in. If it is filled we accept the request and discard it, which is how automated submissions are dropped without telling the sender what gave them away. Submitting twice from the same address updates the existing request rather than queueing another.

We do not use these details for marketing, we do not add you to a mailing list, and we do not sell or share them.

04

Holding an account

An account stores your username, a hashed password, which advertisers you may work on, and whether the account is active or paused. Passwords are stored only as PBKDF2 hashes — we cannot read yours, which is also why there is no self-serve reset.

Signing in issues a token. Signing out, changing your password, or an administrator changing your role immediately invalidates every token previously issued to you. No payment card details are held in this system.

05

Advertising data on the platform

This section describes data processed on behalf of our customers when they run campaigns. It is the part of the system that touches people who never visited this site.

Bid requests

An exchange sends a bid request and the bidder answers inside roughly a tenth of a second. From that request we record the country, the device operating system and device type, and the connecting IP address for fraud and bot filtering.

A cross-request identifier is only derived and stored when the request itself carries a consent signal. If the request does not signal that storage is permitted, no user identifier is taken from it and none is written to our logs — the bid is priced and answered without one. This is enforced in the bidding path itself, not by a downstream filter.

Measurement

When an ad is won and rendered, the creative is wrapped so that an impression can be counted and a click can be routed through our redirect before continuing to the advertiser's destination. That redirect issues a click identifier. When a conversion later happens, the advertiser's network reports it back server to server carrying that identifier, which is how a conversion is tied to the impression that caused it. Duplicate reports are discarded on the network's own transaction id.

The universal pixel

Customers may place our pixel on their own websites. It records page views and conversion events, and it writes a random identifier into their site's local storage under _bm_uid. That identifier is first-party to the customer's website. It is used to build the audience segments they define, and to attribute conversions where no click identifier is available.

06

Cookies and local storage

The complete list. There is nothing else.

NameWhereTypeLifePurpose
dsp_tokenThis site, after sign-inLocal storageUntil you sign outKeeps you signed in to the console
dsp_themeThis siteLocal storageUntil clearedRemembers light / dark / auto
bm_vtOur tracking endpointsCookie90 daysView-through attribution when there was no click
_bm_uidA customer's own websiteLocal storageUntil clearedAudience membership and pixel attribution

The two dsp_ values are strictly necessary to sign in and to honour your display preference, so this site shows no consent banner — there is nothing optional to consent to. bm_vt is set in a third-party context on ad impressions, is marked HttpOnly and Secure, and is unreadable by any page's JavaScript. Where a customer's own consent framework says not to set it, it is not set.

07

Legal bases

  • Contract. Running your account and the campaigns you configure.
  • Legitimate interests. Reviewing access requests, keeping the service available, preventing fraud and abuse, and securing the system. We limit this to what a reasonable person would expect from an operator of a bidding platform.
  • Consent. Any identifier used for advertising measurement, which is why the bidder refuses to derive one when the request does not carry a consent signal.
  • Legal obligation. Where we are required to keep records.
08

Who else sees the data

  • Supply partners and exchanges. A bid response goes back to the exchange that asked for it. That is the transaction; there is no separate data feed.
  • Hosting and infrastructure. The platform runs on Google Cloud in the Mumbai (asia-south1) region, with a managed PostgreSQL database, a managed Redis instance for bid-time counters, and Cloudflare in front of the public domain.
  • Nobody else. We do not sell personal data, we do not share it for anyone else's advertising, and we do not enrich it from data brokers.
09

How long we keep it

  • Access requests — kept while the request is open, and afterwards as a record of the decision. Ask and we will delete a rejected request.
  • Account records — for the life of the account.
  • Bid, impression, click and conversion records — these are the customer's reporting history and are retained while their account is open, because a conversion can attribute back to an impression up to 90 days earlier. A customer can ask us to erase any individual's records at any time and we do it on request.
  • Generated report exports — pruned automatically on a retention window.
  • Server logs — kept for a short operational period.
10

Your rights

Depending on where you live you may have the right to access, correct, delete, port or restrict your personal data, and to object to processing based on legitimate interests. Where processing rests on consent you can withdraw it at any time.

The platform has export and erasure built in rather than bolted on. An erasure request removes the individual's bid records, impressions, clicks, conversions, postback records, pixel events and audience memberships together, in one operation, so no orphaned rows are left behind. An export returns the same set as structured data.

To exercise a right, write to info@brandmongo.com. If you are an end user and you know which advertiser served the ad, they can act faster because they are the controller. If you do not know, write to us anyway and we will identify the campaign and pass it on. You may also complain to a regulator: in India that is the Data Protection Board of India, and in the EEA or the UK it is the supervisory authority for the country you live in.

11

Security

  • HTTPS everywhere, with strict transport security enforced in production.
  • Passwords stored as PBKDF2 hashes; tokens revocable instantly and revoked on sign-out, password change and role change.
  • Accounts are scoped per advertiser, so someone with access to one advertiser's campaigns cannot read another's.
  • A strict content security policy on every page, and the API returns no cross-origin surface beyond what the console needs.
  • Server-to-server conversion reports are authenticated with a shared secret and de-duplicated, so a replayed report cannot inflate anyone's numbers.

No system is perfectly secure. If you find a vulnerability, please report it to info@brandmongo.com before disclosing it publicly.

12

Changes to this policy

If we change how the platform handles data we will update this page and move the date at the top. Material changes affecting account holders are sent by email to the address on the account. Continuing to use the platform after a change means the updated policy applies.

See also the Terms of Service.