We hope this Standard will enable members to be confident their membership and resulting data is treated in a fair, upfront and ethical manner.

Whitelabelling, Shared and Linked Databases

Why are these techniques used?

At their best these techniques benefit the member by combining the powers of "aggregation", "niching", "branding" and "fire-walling" to provide more dating opportunities with like-minded people.

For example in terms of aggregation and nicheing - they provide ability to find lots of people in a special interest group like Classical Music or Single Parents whose memberships are spread across many sites.

In terms of branding they enable lots of non dating brands to extend their presence into dating - thereby bringing lots of cool new members into the online dating world.

In terms of firewalling they provide the ability to keep substantially dis-similar people apart such as people looking for Marriage Vs People looking for merely a Short Term Relationship. By having these on separate databases - one set of people does not upset or annoy the other.

However, at their worst - and particularly in the hands of unscrupulous operators - these techniques can result in a confusing mirror-maze of profiles, data and double billings with the member not really knowing who runs things and showing up on sites of a nature that they would not have consented to had they been made aware.

Requirements - summary

The (potential) member needs to be made aware of the exact relationship between the brand partner and the underlying dating service company, which database(s) their details (profile + messages) will be stored on and which sites they will appear on..

The explanation of the relationship and 'How it all works' needs to be up front, honest and plain speaking so that members know what they are signing up to, who does what and how to access/control their data.

The nature of the whitelabelling arrangement + service should be explained clearly in the Terms of Service - right at the top in plain English

Some whitelabel dating service providers use just ONE database but use clever filtering to segment members according to the many different sites that join their single shared database. Alternatively other dating service providers use multiple databases to provide a more "Hard" segmentation.

If the database provider runs multiple databases (e.g. split into "General", "Adult" , "Mature", etc.) then this needs to be clearly explained to the (potential) member. They need to be specifically told which database(s) they will be joining as a result of their membership of the site. There should also be a listing of which sites link to which database (see below).

Definitions

It is important to define these exactly - as members of the general public sometimes get confused and refer to a "Database" as a "Site" and vice-versa.

Database refers to the actual location where a copy of the member's data is held. This will typically be a single specific SQL, MySQL or Oracle database

Site refers to the website URL that displays the data from the Database. Hundreds of sites may well be linking to one database. As the result of a single registration the member has just one profile
- there are not hundreds of profiles or indeed hundreds of copies of their profile - there is just one single 'atomic' profile that is physically stored in one place (one single database) and so this can be easily and instantly deleted.

Unique Identifier

Each member will be given single Unique Identifier per profile they setup per database. Typically a membership number or username is used as the Unique Identifier - though some providers may use email address.

Profile refers to the copy of the member's details on the relevant database(s). Members login to access their profile by the Unique Identifier

White label dating service provider

This is the company that operates the database(s) which store the data and the software to provide the service

Brand Parter

This is the company that promotes the dating service by using their brand name, links on their site and other promotion. Typically they often have nothing to do with the actual mechanics of operating or administering the dating site.

Hard Filtering

This is where the site/database insists on a specific characteristic in order to allow membership. People who do not match the characteristic are prevented from joining or are removed if it is discovered that they do not match the characteristic

Example 1: A dating provider may run a database of sites that are all for people looking for a long term relationship . Married people looking for an affair would be prevented from joining the site - or removed if they joined secretly and their behaviour discovered

Example 2: A site aimed at exclusively Orthodox Jewish people - would not allow people outside this group to join

Soft Filtering

This is where the site/database is marketed to attract a specific sort of person or where computer techniques are used to search out or favour members with a specific characteristic. Unlike Hard Filtering - the site/database does not physically prevent non-matching people from joining.

Example 1: A site aimed at "Graduates and Professionals" employing soft filtering would not necessarily ban members who did not have a university degree.

Example 2: A site aimed at people who like dancing - may well be linked to a "General purpose" database of dancers and non dancers - but use clever programming to be able to favour dancers in the search lists. There would not necessarily be a hard block on non-dancers contacting the person who like to dance.

Keeping the member informed - true nature of the Site and Database

The potential (member) needs to have given accurate idea of what sort of filtering (if any) is done by the Dating Service Provider on the site + linked database

The Dating Service Provider should not use inaccurate or misleading wording to (potential) members - for example to lead them to believe that the site they are joining is something that is "Exclusive" when it isn't .

Example 1: One would reasonably expect a site marketed as "Just Single Parents" to be hard filtered on this category, not simply joined onto a general purpose database that would include vast numbers of people that did not this category.

Example 2: A "Soft Filtered" site called something like "Kids no problem" presented as a friendly place where single parents are made welcome and where they can search out people who are "Ok to meet single parents" - this would appear fair as it is not providing a misleading impression.

Dating Service Providers and Brand Partners should not mix'n'match facts pertaining to the Site and the Database in a misleading manner. For example a dating site for Salsa Dancers should not state "Meet people who love to dance salsa. 100,000 members" when the 100,000 members are merely members of the general purpose database to which the site is attached.

Keeping the member informed - who has what rights over their data

Typically the Brand Partner does not have responsibility for :

1.Function - their site most likely works exactly the same as other brand partner sites running off the same 'Template'

2.Legality - on signup the Terms and Conditions state the contract is between the member and the Dating Service Provider

3.Admin - they don't answer customer queries or approve profiles - the Dating Service Provider does all that

Dating Service providers need to make the above clear and not lead people to believe the Brand Partner is doing more than they actually do. Dating Service Providers need to be clear that they run the site, have access to the data, do the admin etc. not the Brand Partner if this is the case

Different Brand Partners have different rights over user data according to whatever deal they struck with the Dating Service Provider. The Dating Service providers also need to be clear in the Ts and Cs as to what access/rights to user data the Brand Partner will have. For example
- just summary stats
- ability to see all profiles
- ability to administer profiles
- copy of email addresses for their own marketing purposes
- full data co-ownership such that they could setup their own dating site also in the future

Multiple profiles and databases - keeping the user informed.

Whilst multiple profiles of the same member is an issue for single sites - it is a bigger issue for networked and whitelabelled sites due to the increased possibility of members signing up to two separate sites that use the same shared database and the member being unaware of this.

Unique Identifier - by its name - is unique but only on a per database basis. Members must be clearly told what their unique identifier is and to what database(s) this refers.

If we imagine the dating service provider chooses "Username" as their unique Identifier and operates 2 databases - "General/Younger" and "Mature" then someone with the username "Highlander" cannot have a second profile called "Highlander" on the "General/Younger" Database. If they login as "Highlander" and delete that profile then it is impossible for another "Highlander" to continue to exist on that "General/Younger" database and so "Highlander" will instantly disappear from all the (potentially 100s of) sites that link to the "General/Younger" database.

Members must be told what is and what is not a Unique Identifier. They should not be led to believe it is email address if email address is treated as a non-unique value by the provider. In the above example we could imagine that user "Highlander" also sets up a profile called "Highlander2" on a separate site that links to the same "General/Younger" database but using the same email address as "Highlander". They would not necessarily be refused signup because the email was non-unique. Also logging via email address and deleting "Highlander" would not delete "Highlander2"

The Dating Service Provider upon registration should flag up to the member that they have existing profile(s) on their database on the same email address so they can take appropriate action - e.g.
- abandon the 'new' registration and revamp their old profile
- delete the old profile
- knowingly keep both

The dating service provider should not encourage nor facilitate through failure to disclose information the unwitting creation of multiple profiles of the same person on the same database. However, there are occasions where multiple profile could be considered appropriate as long as the user is aware/informed that they have multiple profiles.

• member is embarrassed to be seen back dating after a break-up site with same old username in search lists but wants to stay in contact with a few people via the old profile.
• member is in a special interest group (e.g. Salsa dancing) and wants a profile that promotes this on the special interest sites as well as a more general purpose profile that would appeal to non-dancers on the main site

Dating Service Providers should provide an online function (e.g. on a My Account, Dashboard or Settings page) for members to check what profiles are associated with their email address. This does not necessarily need to check across multiple databases e.g. whilst logged into a site on the "General" database would not necessarily check the "Adult" database. However the Dating Service Provider must be specific as to what databases) are being checked and provide at least a link to check the other databases.

Dating Service providers must upon emailed request provide members a list of all profiles associated with their email address across all databases - so that the member can avoid unintentional confusion, multiple memberships, double-billing and repeated re-billing after the member had thought they had cancelled all their accounts/profiles.

Moving and Copying between databases (Co-Registration)

Members must give explicit "Opt In" consent to being cloned or moved to a database of a substantially different nature. A clone co-registration from a "General" database to an "Adult" database would most certainly be a "Substantially different nature" and would require "Opt In" not just "Opt Out" consent.

In the case of clones/moves to databases of a similar nature - the Dating Service Provider should give the member 7 days prior notice and "Opt Out" facility of not beiung cloned/moved

Members must be clearly informed when they are being moved or cloned onto another database and given the instant ability to

a) delete the new profile in the case of a "Clone" co-registration
b i) reverse the process in the case of a "Move"
b ii) suspend/delete the moved profile if the "Move" is unacceptable to them and a "reverse" is unacceptable to the dating service provider

Example 1: A typical example of an automatic move is where a member is on an age inappropriate database as they submitted incorrect DOB that gets identified later
This applies where the dating service providers choose to maintain separate databases for "Mature" members - say age 35+ members and an younger database for members say 18-45. If the member is really 53 they cannot demand to stay on the inappropriate "Younger" DB.

Example 2: A typical "Clone" would be where the member is in an overlapping category e.g. aged 42 and the dating service provider chooses to automatically give them a profile on the Mature database as well as the General one which they initially registered on. The Dating Service Provider may do a clone in this case - but the user must be immediately informed and have the chance to instantly delete the clone.

Example 3: Another typical "Clone" would be where the Dating Service Provider judges that member would be more suited to a different database by nature of their profile content. If someone was on a "Graduates+Professionals" database but was a non graduate and somewhat struggling with correct spelling and grammar resulting in them not getting (m)any responses - the Dating Service Provider may schedule to "Clone" them to a more "General" database, as opposed to moving them as this effectively boots them off the "Graduates + Professionals" database and could very well be offensive to the member.

In all cases of "Clones" payment cannot be cloned - the Dating Service Provider cannot assume the member wants to pay to be a paying subscriber to the other database/site. The member must specifically choose to subscribe to the new site as per they did on the original site.

Having dealt with multiple profiles on multiple databases let us look at the more commonplace issue of the single user on a single database who shows up on many sites (linked to that one single database).

Control of who sees my profile on which sites

The member should be able to see on which websites their profile will be displayed
- all sites in the global "Sites List" that attach to their database
- just some grouping of these sites
- just the one site they registered on.

The point of this is for members who signup on something very specific, niche or conservative (note the small "c") e.g. a site aimed at "Just Single Parents" to see where else they will be showing

The member should have the ability to restrict their profile to purely showing up on the one site they joined via a Settings page.

The member should be able to see on all other members' profiles if they are also a member of the site they joined or of an affiliated partner website (i.e. same databse, different website).

To protect commercial interests the Dating Service Provider does not need to publish the exact URL of every partner site. However a description of the site should be provided along with a fair and accurate description of the "Nature" of the partner. For example: .
"A dating site for people who like Classical Music and the Arts run in partnership with a partner who has run Classical Music events since 1997"
"A dating site for mature graduates and professionals (age 40+) in partnership with a leading UK professional traditional introduction agency"
"A site for older people run in partnership with a national monthly magazine"

The dating service provider should not turn down a reasonable request from members to disclose the source URL of a profile.. The member needs to provide justification as to why they want to know the URL. Most typically this is to see if there is a conflict of interests/values
- "I'm a committed Vegan and see that member X comes from a 'Cooking and Dining' related site - please can you give me the URL".
- "I joined a site aimed at Christians and member Y comes from a site aimed at those with 'Alternative Beliefs' - I'm a bit concerned"

The dating service provider may turn down requests where they feel they are made for commercial purposes - i.e. by competitors trying to identify and poach partner sites. If a request is turned down the Dating Service Provider is obliged to give the evidence/reason why they suspect the request is not a genuine member concern but is for commercial purposes

The site should provide a link to a listing of all sites which the (potential) member's details will potentially be viewed on - the "Sites List". As mentioned on a per-profile basis the Dating Service Provider is not obliged to provide the exact URL or partner names to mitigate against partner-poaching by competitors. However a fair and accurate description to enable the (potential) member to judge the nature of the sites they will be exposed on is required.

The listing of partner sites should be real-time and database driven to avoid a static list that gets out of date as soon as it is printed. This will also mitigate against any dating service provider "conveniently" forgetting to add dodgy sites to their list that they would rather people didn't know they were being exposed on.

The Dating Service Provider should also provide members access to a "Database List" via their Terms and Conditions page that lists and describes all the dating-related databases they operate and what Hard + Soft Filtering (if any) applies to each database. For example if they operate just a single Database - it is important for (potential) members to know if there are any universal requirements/rules across the entire database and therefore all attached sites. Most typically potential (members) would be concerned to see if people looking for "Casual" or "Adult" dating are permitted on the database through joining certain attached sites.

We hope this Standard will enable members to be confident their membership and resulting data is treated in a fair, upfront and ethical manner. You can see our Databases and Sites List here .