What the data for this category looks like
Daily data for search ad keyword management includes four core document types: keyword lists, negative keyword tables, bid records, and search term reports. Data sources include search ad backends, search term reports, bidding ranking data, and landing page data. Update frequency is adjusted daily or weekly. Typical fields include keyword text, matching mode, bid amount, click volume, conversion data, and landing page links. This setup supports storage requirements for account data across different campaign scales.
Constraints for Database and Operations Workflows
Data for search ad keyword management comes from multiple sources, requiring integration with multiple ad backends and data interfaces. This demands multi-source connection capabilities for databases. Data is updated in batches daily or weekly, with frequent bulk write operations. Connection configurations must support high-concurrency writes. Core documents include multiple types of structured data, so corresponding table structures and indexes must be designed to ensure efficiency of filtering and matching queries. Data scale grows with the expansion of account campaign scope. Expansion space must be reserved, while ensuring log retention and rapid positioning capabilities during fault troubleshooting.
How to set configurations
| Configuration Item | Recommended Value | Rationale |
|---|---|---|
MONGODB_URI | mongodb://<account>:<password>@<host>:<port>/<database_name>?authSource=admin | Adapts to multi-source unstructured data storage and query pulled from search ad backends and search term reports |
DB_MAX_LINK | 20–30 connections | Adapts to concurrent connection requirements for daily bulk writes of keyword lists and bid records, preventing connection exhaustion |
REDIS_URL | redis://<password>@<host>:<port>/0 | Caches frequently accessed popular keywords and negative keyword data to reduce database query pressure |
PG_URL | postgresql://<account>:<password>@<host>:<port>/<database_name> | Stores negative keyword tables and bidding ranking data that require complex filtering, supporting multi-condition joint queries |
This document was written for FastGPT v4.17.0.
Three common mistakes
- Phenomenon: Database connection errors of the type
Failed to connect to <host>:<port>appear. Cause: Incorrect authentication information, host or port settings forMONGODB_URIorPG_URL, or network firewalls restricting database access permissions. - Phenomenon: Shared pages do not respond after concurrent requests exceed the threshold. Cause: The
DB_MAX_LINKconfiguration value is too low, causing the database connection pool to be exhausted and cannot process new access requests. - Phenomenon: Keyword expansion and negative keyword screening take too long. Cause: No database indexes have been created for frequently queried fields such as keywords and matching modes, triggering full table scans and reducing query efficiency.
How to confirm configurations are properly set
- Check the format and access permissions of configuration items such as
MONGODB_URIandPG_URL. Run basic connection tests to confirm that test keyword or bid data can be retrieved. - View the active connection count of the database connection pool. Confirm it does not reach the
DB_MAX_LINKconfiguration limit. Adjust the configuration threshold based on actual business concurrency. - Simulate bulk write operations for search term reports and keyword lists. Confirm that write speed meets business update frequency requirements, with no write failures.
- View Redis cache hit statistics. Confirm that frequently queried keywords and negative keyword data have been correctly cached to reduce database query pressure.
The values provided are common starting points and should be measured against the reader's own samples.
Question material comes from public community discussions. Configuration values are common starting points and should be measured against your own samples. Verified on 2026-10-19.