Droit d'être oublié (RTBF) pour les magasins de données | Documentation

Droit d'être oublié (RTBF) pour les magasins de données vous permet de déclarer quelles clés et quais magasins de données contiennent les données d'un utilisateur. Lorsque Roblox traite une demande RTBF pour votre jeu, le système utilise ces modèles pour supprimer automatiquement les données correspondantes. Vous pouvez configurer des modèles visuellement via le Gestionnaire de magasins de données dans le Creator Hub, ou de manière programmatique via l'API Open Cloud Configs API.

RTBF automatisé

Pour utiliser le traitement RTBF automatisé, vous devez définir des modèles de suppression. Ces modèles indiquent à Roblox quels magasins de données ou clés appartiennent à un utilisateur spécifique. Vous pouvez avoir jusqu'à 100 modèles pour identifier vos données utilisateur.

Modèles de suppression

Le RTBF automatisé fonctionne en faisant correspondre des modèles. Vous définissez un modèle pour vos données utilisateur en utilisant un jeton {UserId}. Lorsque Roblox reçoit une demande de droit d'être oublié, le système remplace ce jeton par l'ID réel du demandeur et examine vos magasins de données à la recherche de correspondances à supprimer.

Exigences d’éligibilité

Pour qu'une entrée soit éligible à la suppression automatisée, elle doit répondre aux critères suivants :

Type de stockage — Les données utilisateur doivent être stockées dans un magasin de données standard ou un magasin de données ordonné. La suppression d'un magasin de données entier est prise en charge uniquement pour les magasins de données standard.
Identifiant — L'ID utilisateur doit faire partie du Name ou du Scope du magasin de données ou de la clé.
Format — L'ID doit être identifiable via un modèle de chaîne statique (par exemple, User_{UserId}).

Configurez le RTBF automatisé via le Gestionnaire de magasins de données

Le Creator Hub propose une interface visuelle pour gérer vos modèles RTBF sans utiliser la ligne de commande.

Pour les jeux de groupe, vous devez ajouter la permission Voir les analyses pour voir les configurations, et la permission Modifier et publier l'expérience pour voir, modifier et publier les configurations. De plus, l'utilisateur lui-même doit être éligible pour publier des jeux.

Accédez au Creator Hub.
Sélectionnez le jeu que vous souhaitez configurer.
Dans le menu de navigation à gauche, allez dans Configurer ⟩ Gestionnaire de magasins de données.
Sélectionnez l'onglet Suppression RTBF.
Cliquez sur Créer un modèle.
Sélectionnez le Type (Magasin de données standard, Clé standard, ou Clé ordonnée).
Saisissez les champs correspondants avec votre modèle en utilisant le jeton {UserId} (par exemple, PlayerInventory_{UserId}). Ce jeton est sensible à la casse.
Vérifiez la sortie d'exemple et cliquez sur Créer.

Configurez le RTBF automatisé via l'API Configs

Vous pouvez également gérer les modèles RTBF de manière programmatique en utilisant l'API Open Cloud Configs. Cela est utile pour l'automatisation ou la gestion de modèles à grande échelle.

Dans le Tableau de bord Creator, créez ou modifiez une clé API pour inclure les permissions universe:read et universe:write pour chaque univers où vous souhaitez automatiser la suppression RTBF. Pour plus de détails, voir Gérer les clés API.

Les modèles sont stockés sous forme de configuration JSON nommée user_data_templates. Il existe deux types principaux :

Modèle de clé — Identifie des clés spécifiques. Nécessite data_store_type (STANDARD ou ORDERED), data_store_name, et key_pattern. scope_pattern est optionnel mais recommandé.
Modèle de magasin de données — Identifie un magasin de données entier. Nécessite data_store_type (actuellement, ne prend en charge que STANDARD) et data_store_pattern.

Pour les deux types de modèles, le jeton {UserId} est remplacé par l'ID de l'utilisateur lorsque la demande RTBF est traitée.

Configuration Exemple
{
	"user_data_templates": [
		{
			"key_template": {
				"data_store_type": "STANDARD",
				"data_store_name": "PlayerInventory",
				"key_pattern": "User_{UserId}",
				"scope_pattern": "Scope_{UserId}"
			}
		},
		{
			"key_template": {
				"data_store_type": "ORDERED",
				"data_store_name": "PlayerLeaderboard",
				"key_pattern": "User_{UserId}",
				"scope_pattern": "global"
			}
		},
		{
			"data_store_template": {
				"data_store_type": "STANDARD",
				"data_store_pattern": "Player_{UserId}_Save"
			}
		}
	]
}

Le jeton {UserId} est sensible à la casse. Si scope_pattern est omis ou vide, il est par défaut global.

Ensuite, soumettez via l'API Open Cloud Configs API. Dans les exemples suivants, remplacez <API_KEY> et <UNIVERSE_ID> dans chaque requête, et envoyez toutes les requêtes au dépôt DataStoresConfig.

Pour des points de terminaison et un comportement supplémentaires, consultez la référence API Cloud et le guide des configurations d'expérience.

Créez un brouillon via une requête PUT qui définit votre configuration. Si un brouillon existe déjà, cette requête l'écrase.


curl --location --request PUT 'https://apis.roblox.com/creator-configs-public-api/v1/configs/universes/<UNIVERSE_ID>/repositories/DataStoresConfig/draft:overwrite' \
	--header 'x-api-key: <API_KEY>' \
	--header 'Content-Type: application/json' \
	--data-raw '{
	"entries": {
		"user_data_templates": [
			{
				"key_template": {
					"data_store_type": "STANDARD",
					"data_store_name": "PlayerInventory",
					"key_pattern": "User_{UserId}",
					"scope_pattern": "Scope_{UserId}"
				}
			},
			{
				"key_template": {
					"data_store_type": "ORDERED",
					"data_store_name": "PlayerLeaderboard",
					"key_pattern": "User_{UserId}",
					"scope_pattern": "global"
				}
			},
			{
				"data_store_template": {
					"data_store_type": "STANDARD",
					"data_store_pattern": "Player_{UserId}_Save"
				}
			}
		]
	}
}'

Vérifiez votre brouillon via une requête GET pour récupérer et examiner le brouillon avant qu'il ne soit mis en ligne.


curl --location --request GET 'https://apis.roblox.com/creator-configs-public-api/v1/configs/universes/<UNIVERSE_ID>/repositories/DataStoresConfig/draft' \
	--header 'x-api-key: <API_KEY>'

Après vérification, envoyez cette requête POST pour publier. La seule manière d'annuler cette action est de restaurer une version précédente. Cette action nécessite également que le compte associé à la clé API soit éligible pour publier des jeux.


curl --location --request POST 'https://apis.roblox.com/creator-configs-public-api/v1/configs/universes/<UNIVERSE_ID>/repositories/DataStoresConfig/publish' \
	--header 'x-api-key: <API_KEY>' \
	--header 'Content-Type: application/json' \
	--data-raw '{
	"deploymentStrategy": "Immediate"
}'

Après publication, confirmez que la configuration est en ligne avec cette requête GET.


curl --location --request GET 'https://apis.roblox.com/creator-configs-public-api/v1/configs/universes/<UNIVERSE_ID>/repositories/DataStoresConfig/full' \
	--header 'x-api-key: <API_KEY>'

Meilleures pratiques

Sensibilité à la casse — Utilisez le jeton exact {UserId} dans vos modèles. Des variantes comme {userId} ne sont pas acceptées.
Vérification manuelle — Comparez vos modèles avec votre utilisation en direct de Luau en utilisant le Gestionnaire de magasins de données dans le Creator Hub avant de publier la configuration.
Scopes par défaut — Si un magasin de données utilise le scope par défaut, définissez scope_pattern sur "global" dans le modèle de clé.
Tester le flux de bout en bout sur un jeu test — Pour une validation complète de vos modèles, envisagez de créer un jeu test et un compte fictif, en le peuplant avec des données fictives pour l'ID utilisateur de ce compte, en demandant RTBF sur le compte fictif et en vous assurant que les données sont supprimées une fois le compte traité.
Confirmer les suppressions — Après intégration dans votre jeu en direct, lorsqu'une demande RTBF apparaît dans vos messages Roblox, vérifiez que les données correspondantes ont été supprimées dans les 30 jours.