Privacy Policy

1) Controller and scope

This policy covers Yahalaly account registration, profiles, values answers, preferences, recommendations, photos, matches, messaging, guardian features, support, moderation, security, and service communications.

The data controller is YaHalaly · Legal operator: Firas Mbarek · Eugen-Broel-Str. 25, 50169 Kerpen, Germany · Email: support@yahalaly.com. Privacy contact: privacy@yahalaly.com.

2) Data we process

• Account data: email address, password hash, self-declared date of birth, gender, matching direction, account status, role, and security settings.
• Registration-entry data: when a recognized Yahalaly registration link supplies one, a single fixed allowlisted entry-page label is stored with the account so registration and activation cohorts can be compared. It does not contain the page URL, raw referrer, campaign text, query string, or anything entered in a public tool. This account-level label is separate from optional aggregate analytics and does not depend on the analytics choice.
• Profile and preference data: display name, location, languages, biography, relationship intention, marriage timeline, children, relocation, work style, family involvement, education, occupation, lifestyle, and the optional physical or family fields you choose to provide.
• Religion-related and potentially sensitive data: practice level, prayer frequency, religion, religious values, Qur'an reading, service attendance, conversion, hijab or niqab choices, ethnicity, and values answers. These fields can reveal religious beliefs or ethnicity and may receive special protection under applicable law.
• Photos and photo controls: uploaded originals, delivery derivatives, moderation state, chosen visibility, reveal requests, and reveal decisions.
• Optional no-photo feedback: if you finish onboarding without a photo, you may select one fixed reason to help improve that step. No free text, filename, image content, device detail or raw file size is collected with this event. If you do not select a reason, no reason is stored. The choice never affects profile approval or matching.
• Interaction data: recommendations, scores, shared priorities, possible friction, views, likes, saves, passes, matches, blocks, and conversations.
• When enabled, we may keep a private timestamp from a successfully saved qualifying Like or ordinary direct text message, updated at most once per hour. We use it alongside sign-in time to assess whether your profile can appear in discovery. Passive reads and refreshes do not update it. It is not derived from message content, does not change public online or last-active displays, is not shared with advertisers, and is cleared on account erasure.
• Guardian data: invitation email, mode, acceptance state, connection, consent settings, and guardian-group participation.
• Trust and safety data: profile or photo review, self-attestation statements, reports, report evidence, moderation notes and actions, fraud or abuse signals, and audit records.
• Technical and communication data: IP address, user agent, session records, timestamps, security logs, transactional email state, delivery failures, support messages, and limited first-party product events.
• Optional support diagnostics: if you start troubleshooting, fixed screen, action and technical-result labels are held only in this page’s memory for up to 30 minutes. Nothing is sent until you choose to share. A shared report is linked to your account and includes your language, narrow/wide layout category, relative event times, coarse loading durations and optional API request references. It never includes message text, entered answers, photos, raw URLs or mouse movements. Reports expire after seven days and are deleted by routine bounded cleanup; account deletion removes them. Authorized support reviewers need a recorded reason, and access is audited. This is separate from advertising and aggregate analytics.
• Voluntary product feedback: when you choose to send it, we store your selected topic, fixed screen label, language, optional written comment and submission time with your account. A submission key prevents duplicate feedback, not visitor tracking. Feedback is visible only to authorized staff; opening account-linked comments requires a recorded reason and is audited. Raw feedback expires after 30 days and is removed by bounded cleanup or account erasure. It is not sent to advertisers or used as a moderation strike. No message history, mouse movements or typed fields elsewhere are collected.
• For account-security and abuse reviews, authorized administrators can compare the country stated in a profile with the approximate country and region inferred from IP addresses in retained successful sign-in records. Lookups use a local database; member IP addresses are not sent to its provider. Results are generated on access, not stored as a separate location history, and do not extend the retention of the underlying security records. This is not GPS, a verified residence, or continuous location tracking. Mobile networks, travel, VPNs, and database errors can produce mismatches; a mismatch does not automatically restrict an account. Access is reason-gated and audited.
• Fixed public share images: Yahalaly can serve published blank prompt cards and a localized women-first campaign card. These images and their fixed QR destinations contain no account, profile, member, recipient, or referral identifier. If optional aggregate analytics is allowed, only the fixed image-share or image-download action label can be counted; the image, caption, link, destination, delivery, saving, and download completion are not sent with that count.
• Optional first-party aggregate analytics: after an explicit allow choice, daily totals can count a fixed public-page or signed-in trusted-invitation key, the first consented channel in the current tab, and one fixed action. Public actions include page views; public-tool actions; registration-button clicks, form views, submit attempts and coarse outcomes; and completed new registrations. Signed-in trusted-invitation actions are prompt view, WhatsApp open, successful native-share handoff, or successful copy. Fixed channel labels cover direct, search, public sharing, named referral sites, social platforms and tagged ads. Public counter requests contain only fixed page, channel and action labels and are sent without account credentials, cookies or a referrer. The aggregate does not contain an event, visitor, session, user, account, profile, recipient, destination or referral identifier, exact event time, IP address, user agent, raw referrer, URL, query string, raw campaign name, device, inferred country, draft, selection, generated text, clipboard content, invitation text, share destination or tool content.
• Facebook campaign measurement remains first-party and optional. Recognized links become fixed Facebook, Facebook advertising, or Arabic/French Morocco-pilot ad labels; these describe the ad, not a member's language or location. A current consented tab label may also be sent with existing email-verification and profile-save actions so that their first successful completion increments an anonymous daily counter. The label is not saved to the member, audit log or individual product-event record. Later actions in another tab or device may be unattributed. These counts are not a joined member journey. No Meta Pixel or Conversions API is used and this measurement sends no data to Meta. Declining analytics stops future counting and clears the tab label.
• Landing-page layout experiments: Arabic and French marriage pages may randomly show one of two layouts on a page render, without an assignment cookie or visitor identifier. If optional analytics is allowed, a fixed language/layout label (Arabic A or B, French A or B) is kept in the current tab and daily aggregate totals count page views, signup actions and first successful account, verification and profile-completion actions. The label is not attached to member records, individual events or audit logs, and nothing is sent to advertising platforms. Reloads can receive another layout; these counters measure exposures, not unique people. Declining analytics clears the tab label. The totals follow the same 400-day retention limit as other optional aggregates.
• Separate server request totals: when a full-document GET request reaches the Arabic or French women's marriage landing page, the server may increment a daily total for that fixed page. Ordinary request headers are checked transiently to exclude identifiable bots, link previews and prefetches; no extra browser request, cookie, device storage or visitor identifier is used. This counter stores only the UTC date, fixed page label and total. A single service-wide collection-start timestamp explains which days have coverage. It does not store IP addresses, user agents, referrers, query strings, ad IDs, accounts, layout variants or individual event times, and sends nothing to Meta, Google or another advertising platform. Daily totals are kept for up to 400 days; collection-start metadata remains while this counter operates. This operational aggregate is separate from optional browser analytics and does not use the analytics-choice cookie. Requests are not unique people or confirmed successful visits; reloads, shared links and unidentified automation can add requests. Existing security and infrastructure logs are separate, as described above.

3) Where data comes from

• From you when you register, complete a profile, answer questions, upload a photo, interact, contact support, or submit a report.
• From the recognized Yahalaly entry-page label carried by a registration link. The registration form displays this account-level processing when such a label is present; raw URLs, referrers, campaign text, query strings, and public-tool entries are not copied into it.
• From other members when they interact with or report your account.
• Automatically from your browser, device, and service activity for authentication, security, reliability, and first-party product operation.
• For optional first-party aggregate analytics, the browser locally maps an allowlisted utm_source value or referring hostname to a fixed channel. Named AI-assistant, launch, directory, publication, and social channels in the allowed list have distinct labels; remaining referrers use fixed search, social, external, internal, or direct categories, and an unrecognized non-empty campaign source becomes only other external. Raw referrers, URLs, campaign names, and unrecognized campaign values are not copied into same-tab attribution storage or sent to the aggregate-analytics endpoint.
• From infrastructure and email providers when they return delivery, bounce, complaint, or security information.

4) Why data is used

• Create and secure accounts, confirm email control, maintain sessions, and provide requested settings.
• Display eligible profiles and apply mutual direction, age, location, preference, block, and dealbreaker filters.
• Calculate and explain compatibility recommendations from values, intention, lifestyle, and profile-completion inputs.
• Deliver photos according to selected visibility, mutual-match state, and accepted hidden-photo reveal choices.
• Create matches, messages, notifications, and optional guardian connections or group conversations.
• Review profiles and photos, receive and investigate reports, enforce rules, prevent abuse, and preserve service integrity.
• Respond to support and rights requests, deliver essential service emails, debug failures, and meet legal obligations.
• Measure first-party feature operation, including aggregate counts of optional fixed no-photo feedback, and improve reliability. Separately, optional Google Ads measurement can count email-verified registrations following an ad click, only after explicit consent.
• Compare registration and activation cohorts using the fixed allowlisted entry-page label stored with an account, without retaining a raw referring URL or anything entered in a public tool.
• When you allow it, count public-page views, fixed public-tool stages (start, use, link share, copy, print, blank-card image-share attempt, and blank-card image-download initiation), signed-in trusted-invitation stages (prompt view, WhatsApp open, successful native-share handoff, or successful copy), registration-button clicks, and genuinely new completed registrations in aggregate to understand which fixed channels and content are useful. Image actions describe the requested browser action, not confirmed delivery or completion. Member, profile, recipient, or destination identifiers, invitation text, tool entries and outputs, selections, generated text, and clipboard content are never sent with these counts. Do Not Track, Global Privacy Control, and automated-browser signals disable this collection even when the saved choice says allow. Duplicate or rejected registration attempts do not increment the signup aggregate.

5) Legal bases and sensitive fields

Depending on the processing and your location, Yahalaly relies on performance of the service contract, legitimate interests in account security, safety, fraud prevention and reliable operation, compliance with law, and consent where required.

Optional profile fields can reveal religious belief or ethnicity. Registration records a separate explicit choice for sensitive-data processing before those matchmaking features are used. You then decide which optional fields to provide. Withdrawing consent stops future consent-based use, but does not make earlier lawful processing unlawful; withdrawal may require erasing the account where sensitive matching cannot otherwise continue.

Reports and safety records may contain sensitive information. They are processed where necessary to protect members, establish or defend legal claims, comply with law, or on another basis available under applicable data-protection law.

Optional first-party aggregate analytics runs on consent. Declining or withdrawing the choice does not affect public or signed-in account access. A signed-in trusted-invitation action never turns analytics on; it is counted only if the current consent version already records an allow choice. When allowed, the first channel detected after consent is kept in same-tab session storage until the tab closes; it is removed on decline and ignored or removed when supported browser privacy or automation signals apply. Withdrawal stops future collection; existing daily totals cannot be connected back to a person because neither the aggregate nor the same-tab value contains a visitor, session, user, account, profile, recipient, or destination identifier.

6) Matching and profiling

Yahalaly uses structured profile fields, preferences, and values answers to filter and score possible introductions. Values alignment contributes up to 60 points, matching marriage intentions up to 25, and lifestyle or profile context up to 15. The viewer's own importance weights influence the values score, so two people can see different directional context.

Compatibility scoring does not use private message content to predict a relationship and does not make a legal or similarly significant decision. Members choose whether to like, pass, match, reveal a photo, message, involve a guardian, block, or report. A score is not a safety check or marriage prediction.

You can change preferences and values answers, inspect the factors shown with a recommendation, or decline any introduction. More detail is available on the public Matching Methodology page.

7) Who receives data

With separate explicit consent, Google receives an advertising click identifier, a confirmed-registration event, a random one-time event identifier and technical IP/browser information from a standalone confirmation page. This can reveal interest in Muslim matchmaking. It is not anonymous measurement. No name, email, account ID, verification token, profile content, photos or messages are sent. No personalised advertising, remarketing, enhanced conversions or member-list uploads are enabled. Refusal does not affect account access. Privacy choices lets you withdraw at any time; future requests stop and local attribution is cleared, but withdrawal does not undo data already sent. Google processing may include countries outside your own. Details, storage durations and provider links are in the Cookie Policy. Yahalaly does not sell personal data.

• Other eligible members receive the profile fields and photo version allowed by your settings and the interaction context.
• A guardian connection alone grants no profile, match, photo, direct-message, or conversation access. If both matched adults approve a named chaperone for a specific match, that account can access only the new, separate guardian group conversation while it remains active; inviting a guardian discloses the invitation email and chaperone purpose to that recipient.
• Authorized moderators and support personnel access information when needed for review, assistance, security, or rights requests.
• Amazon Web Services supports cloud hosting and transactional email delivery in the current deployment. Provider access is limited to operating those services and subject to contractual and legal safeguards.
• Professional advisers, authorities, courts, or emergency recipients may receive limited data when legally required or necessary to respond to serious harm or establish legal claims.
• A buyer or successor may receive data in a genuine corporate transaction subject to confidentiality and applicable notice requirements.

8) International transfers

Infrastructure or support processing may involve a country outside your own. Where a restricted international transfer occurs, Yahalaly must use an available legal mechanism such as an adequacy decision, approved contractual clauses, and supplementary safeguards where required. You may ask privacy@yahalaly.com for information about the mechanism relevant to your data.

9) Retention and account closure

Account and profile data, values, preferences, photos, matches, and messages are kept while the account is active because they provide the service. Session and one-time-token records are retained until expiry, revocation, use, and operational cleanup. Reports, moderation actions, email-suppression records, and audit data may be retained longer when reasonably necessary for safety, repeat-abuse prevention, legal compliance, or legal claims.

The in-product erasure control verifies the member's password and, when enabled, two-factor code; removes profile, preferences, values answers, photos and stored photo objects, interactions, messages, sessions, notifications, guardian links, and related account records; and replaces direct account identifiers with a restricted deletion tombstone. Billing events are unlinked from the member account.

When content was already attached to a safety report, a limited evidence snapshot may be preserved for safety review, repeat-abuse prevention, legal obligations, or legal claims. Audit records and a pseudonymized, access-restricted deletion record may also remain for traceability. These exceptions do not permit continued matchmaking use of erased profile data.

Exact deletion schedules differ by record type and cannot be shortened where preservation is legally required. Yahalaly will publish a more specific operational retention schedule when automated erasure jobs are implemented and verified.

Optional first-party analytics from public pages and the signed-in trusted-invitation prompt is stored only as daily aggregate counters and is retained for up to 400 days. The consent-choice cookie lasts up to one year unless you replace or delete it sooner. The first consented channel exists only in session storage for the current browser tab and is normally removed when that tab closes, or sooner if you decline analytics.

10) Your rights and controls

Send requests from the registered email to privacy@yahalaly.com. Yahalaly may request proportionate information to confirm the requester is the account holder and will respond within the period required by applicable law. Optional analytics can also be withdrawn immediately through Analytics choices; aggregate counters cannot be retrieved for or linked to an individual.

• Access: request confirmation and a copy of personal data; an in-product export is also available for core account information.
• Correction: update editable fields or ask support to correct inaccurate information.
• Erasure: use the authenticated account-erasure control or request assistance, subject to limited lawful retention exceptions.
• Restriction or objection: ask to limit processing or object to processing based on legitimate interests where applicable.
• Portability: request eligible data you provided in a structured format where the law grants this right.
• Consent: withdraw consent for future consent-based processing without affecting earlier lawful processing.
• Complaint: contact the competent data-protection supervisory authority in your country or place of work, or where you believe an infringement occurred.

11) Security

Yahalaly uses password hashing, HTTP-only session cookies, CSRF controls, role-based access checks, photo authorization, audit records, and operational monitoring. Access is limited by role and purpose. No online service can promise absolute security, so use a unique password, enable two-factor authentication when available, and report suspicious access promptly.

12) Adults only

Yahalaly is for adults 18+ and does not knowingly offer matchmaking to children. The date of birth entered at registration is self-declared. If you believe a minor has created an account, contact safety@yahalaly.com so the account and related data can be reviewed promptly.

13) Changes and contact

Material changes will receive a new effective date and, where appropriate, an in-product or email notice. Changes do not retroactively create consent where consent is legally required.

For privacy questions, rights requests, or the relevant transfer safeguard, contact privacy@yahalaly.com. For urgent platform misconduct, use the in-app report first and contact safety@yahalaly.com. Yahalaly is not an emergency service.