Business Model
This client operates several dating services using a freemium model. In practice, users can access the service for free on a daily basis, but they are limited to five replies per day. To use the service further, the user must subscribe to a plan with a trial offer that includes 20 replies. Once the 20 replies are used, the subscription is automatically activated. With a subscription, the user receives a number of credits, which are consumed with each reply received. If the user runs out of credits, they can purchase extra credit packs to continue chatting while waiting for the next subscription renewal. The services are available in English and German, and operate in multiple countries: USA, UK, AU, DE, and AT. Some services are aimed at serious dating, others are adult-oriented and sexual in nature. Only male users pay for and interact with the animated profiles.Global Settings
We start by creating two projects: one for adult services and another for mainstream services. On the mainstream services, we set theenableSexualTextContent parameter to false with the requests to prevent sexually explicit replies.
This keeps those Personas casual in what they write: it removes flirty replies as well as explicit ones. If you would rather keep the flirting and only rule out explicit replies, lower the Persona’s sexualDrive instead, as explained in Control Sharing and Sexual Intensity.
On the adult services we leave it enabled, and we raise the Persona’s sexual drive. How far each Persona goes, and what she is willing to send when a user asks for a photo, is covered in Control Sharing and Sexual Intensity.
Photo and video sharing require Chat Model 2.0 or above (see Model Versions). The
dating-smart-1 and dating-pro-1 models used in the examples below predate it and do not support it, so pictureSharingMode and shareablePictures have no effect on them.EN_AU as the language parameter. If it’s in England, we use EN_UK.
We let DumGum handle the profile personality definition via the Soul Engine feature.
But since we don’t want replies of 500 words, we set the maximum reply length to LONG, using the project configuration page.
Still on the project configuration page, we enable the Multiple Messages Per Reply option.
This splits one reply into several messages, making conversations more dynamic and natural.
For example, instead of a single message like “Hey Anthony! How are you this morning? I’m exhausted, didn’t sleep well, it’s way too hot lately 🥵”, the reply will be split into multiple messages.
We’ll receive “Hey Anthony! How are you this morning?” followed by “I’m exhausted, didn’t sleep well, it’s way too hot lately 🥵”.
Since the Multiple Messages Per Reply option is enabled, we prefer using DumGum to manage the delay between replies.
To do that, we set the parameter replyParameters.replyTypingDelay to NORMAL.
This way, DumGum will send the messages itself with a realistic delay between them.
For example, “Hey Anthony! How are you this morning?” will be received first, then “I’m exhausted, didn’t sleep well, it’s way too hot lately 🥵” will arrive 15 seconds later.
To display typing indicators like “Mary is writing something…” on the chat interface, we use answer.processing events sent by DumGum when reply generation starts.
This allows us to show typing before the reply is received.
We set up specific monitoring for conversationStopReason.
In particular, we forward cases of type USER_UNDERAGE to our internal moderation to deactivate the relevant accounts.
For other cases, we regularly check the affected conversations to ensure there’s no misclassification.