Privacy Policy

SazzMedia Outreach · Last updated 2 November 2026

1. Who we are and what this policy covers

SazzMedia Outreach is a private web application run by SazzMedia in Bangladesh to plan, send and track SazzMedia's own business outreach email. It is not offered to the public: there is no sign-up, and only SazzMedia's operator can sign in.

This policy explains how the application handles two kinds of information: (a) data from the Google account that the operator connects, and (b) the business contact details of the people who are, or may be, emailed. If you are one of those people, sections 2, 8 and 9 are for you.

2. The information we handle

Google account data (from the connected Gmail account)

• Account details. The email address of the connected account, and the sender name the operator chose for it.
• Authorisation. A Google refresh token that lets the application keep working without asking the operator to sign in again, and the list of permissions that were granted. The token is stored only in encrypted form.
• Emails we send. A copy of each email the application sends (recipient, subject, text, send time and Gmail identifiers).
• Incoming mail. The application reads the connected mailbox to find replies, bounces and opt-out requests. When an account is first connected it looks at the last 14 days; afterwards it looks at new mail, and from time to time searches the last 2 days. These searches cover the whole mailbox, including Spam and Trash, so the application briefly reads the content of every message it finds in order to decide whether the message has anything to do with SazzMedia's outreach. What it then keeps depends on that decision, as described below.

What is kept from incoming mail. For the kinds of message the application has to act on, it keeps the sender's address, the subject (first 300 characters), the message text (with quoted earlier text removed and the length capped), Gmail's identifiers, the time received and a label such as positive or negative. These are:

• replies to our emails, and automatic replies to our emails (for example out-of-office notices), so that follow-ups stop or pause;
• opt-out requests, including from an address we never emailed, so that the address can be added to the do-not-contact list;
• bounce notices (delivery failure reports), because the health of the sending mailbox depends on them.

Every other message (ordinary personal mail, newsletters, notifications, anything not connected to our campaigns) is read only to recognise it as unrelated and is then discarded. For it the application keeps only Gmail's own message and conversation identifiers and the time it arrived. It does not keep the sender's address, the subject, the message text, the message's header identifiers or any label derived from its content. This identifier-only record exists so that the same message is not processed again, and so that the operator can open the message in Gmail from the application's inbox screen if it is flagged there for a look.

Business contact data (the people we may email)

• Email address, name, company, job title, website, industry, country, state or city, time zone, where the contact came from, the operator's own notes, and the lead's status and email-verification result.
• Contact lists are prepared by SazzMedia (for example from files the operator uploads). The application can also read a business's own public website to find a published contact address. It does not buy lists, and it does not read social media pages.
• A do-not-contact list of addresses that opted out, bounced permanently, were marked as the wrong person or no longer at the company, or were added by hand.

Operating records

• An activity log of actions taken in the application (what was done and when, without message text), a queue of background tasks, and settings.
• Counts and statuses used for reports and for notices sent to the operator (see section 5).

3. How we use it

• To send the emails the operator approved, from the connected account, and to keep track of what was sent.
• To recognise replies, bounces and opt-outs, stop follow-ups to anyone who answered or opted out, and show replies to the operator in the application's inbox screen so the operator can answer personally.
• To keep the do-not-contact list, so that nobody who opted out is emailed again.
• To rank leads for the operator's review, and to produce counts of emails sent, replies, opt-outs and bounces. The ranking is a number shown to the operator; it does not send anything or decide who is emailed.
• To keep the application secure and working.

We do not sell personal data, we do not use it for advertising, and we do not use Google data for any purpose other than the ones listed in this section.

4. Google user data and the Limited Use requirements

The application asks for two Gmail permissions, and no others:

• gmail.readonly (read your email): used only to find replies, bounces and opt-out requests, and to show replies to the operator.
• gmail.send (send email on your behalf): used only to send the emails the operator approved from the connected account.

• No deleting or changing mail. The application does not delete, modify, label, archive or mark as read anything in Gmail.
• No advertising, no sale. Google user data is not used for advertising and is not sold or transferred to third parties, except as described in section 5, as necessary to operate the features above, or if the law requires it.
• No AI on Gmail content. Gmail content is not sent to any AI provider and is not used to train any AI or machine-learning model. Reply drafting and reply classification by an AI service exist in the software but are switched off for Gmail content. This policy will be updated before that changes.
• Human access. Gmail data is shown only to the signed-in operator through the application, and is read by people only to operate, support and secure the application or if the law requires it.

5. Who receives information

Information is shared only with the services needed to run the application:

• Google: the application talks to the Gmail API to read and send mail, as described above.
• Suer Cloud Hosting BD: provides the server on which the application and its database run (see section 6).
• Telegram: the operator can receive notices through a Telegram bot. These contain counts and statuses (for example how many emails were sent or how many replies arrived) and, in two kinds of alert, the address of the operator's own connected mailbox. They do not contain recipients' names or addresses or any message text.
• Google Drive (backups): encrypted backup copies of the database (see section 8) are kept on the operator's computer and uploaded to a Google Drive account used only for backups. The backups are encrypted before they leave the server and the key to open them is not stored on the server or in Google Drive.
• An AI provider (optional, never for Gmail content): the application has an optional feature that writes a short opening line from the text of a business's own public website. If it is used, a few sentences taken from that website, the business name and the website address are sent to OpenRouter, which is configured to route to a single named model provider with provider data collection set to deny. The recipient's name, job title and email address are not sent, and Gmail content is never sent.

We may also disclose information if the law requires it.

6. Where information is stored

The application and its database run on a virtual server provided by Suer Cloud Hosting BD. The operator works from Bangladesh and uses the application over an encrypted connection. Encrypted backup copies are stored on the operator's own computer and in a Google Drive account used only for backups.

7. How we protect it

• The dashboard is served only over HTTPS, and the server tells browsers to keep using HTTPS.
• The Google refresh token is stored encrypted (AES-256-GCM). The encryption key is kept in a settings file on the server that can be read only by the application's own service account and the administrator.
• The database accepts connections only from the server itself, and the server's firewall allows only web traffic and administrator login. Administrator login uses keys, not passwords.
• The dashboard needs a password. Repeated wrong passwords temporarily lock sign-in, and signed-in sessions expire (after 24 hours unless changed). Forms accept only requests that come from the dashboard itself.
• The application is built not to write tokens or passwords to its logs.
• Every email needs the operator's approval before it can be sent, and a master switch stops all sending at once.
• Backups are encrypted (AES-256-GCM) before they leave the server, and the key to open them is not on the server.

No system is completely secure. In particular, the dashboard uses a single password and does not use two-factor sign-in.

8. How long we keep it

• Lead, email and reply records: kept while the application is in use (the identifier-only records of unrelated mail described in section 2 contain no personal content). Our target is to keep personal data no longer than 24 months. Automatic deletion is not switched on yet, so for now older records are removed when someone asks (section 9) rather than by the system itself.
• Do-not-contact list: kept without a time limit. It holds only the address, the reason, an optional short note and the date, because deleting it would risk emailing someone who asked us to stop.
• Gmail refresh token: kept until access is withdrawn, the account is reconnected (which replaces it), or deletion is requested.
• Backups: a nightly backup is kept on the server for 7 days (readable only by the administrator account). An encrypted copy is kept on the server for 14 days for collection. The most recent 60 encrypted nightly copies are kept on the operator's computer and in the backup Google Drive account; older copies are removed in a separate step that the operator approves each time, so some may last longer. Data that has been deleted from the application can therefore remain in encrypted backups for about two months or a little longer.
• Telegram notices are kept by Telegram under its own policy.
• Server logs: the web server is not set up to keep access logs. The server's system logs follow the operating system's default rotation, which is based on size, not on a fixed period.

9. Your choices: deletion, opt-out and revoking access

If you received an email from SazzMedia

• Opt out: reply to the email with the word "stop" (or follow the opt-out line in the email). You will not be emailed again.
• Ask for your data to be deleted, or to see or correct it: email sazzmediateam@gmail.com. We will remove your personal details from the lead and message records. We keep your email address on the do-not-contact list so that you are not emailed again; tell us if you object to that. At present deletions are carried out by the operator by hand, because there is no automated tool for it yet.

If you are the operator who connected a Google account

• Revoke access at any time: open myaccount.google.com/permissions, choose SazzMedia Outreach, and select Delete all connections you have with SazzMedia Outreach (or Remove access). Google then refuses the application's token. The application notices, marks the mailbox as needing reconnection and stops sending from it.
• Delete the stored token and Gmail-derived records: email sazzmediateam@gmail.com. The application does not yet have a Disconnect button, so this is done by the operator by hand. Your Gmail messages themselves are never deleted by the application.

10. Cookies

After the operator signs in, the application sets one essential session cookie (HTTP-only, sent only over HTTPS, valid for up to 24 hours). There are no advertising or analytics cookies and no third-party trackers. These public pages set no cookies.

11. Changes to this policy

If the application changes in a way that affects this policy, we will update this page and its date before the change takes effect.

12. Contact

SazzMedia, Bangladesh. Privacy questions and requests: sazzmediateam@gmail.com.