--- title: "Wie weit sollte eine Beschaffungscode-Suche reichen?" description: "Testen Sie Exact-, Parent- und Child-Suchen im festen Zeitraum und übernehmen Sie nur Expansionen, deren zusätzliche Treffer den Review-Aufwand rechtfertigen." canonical: "https://zephior.com/de/insights/expand-tender-codes-without-drowning-in-noise" last-updated: 2026-09-02 --- # Wie weit sollte eine Beschaffungscode-Suche reichen? > Testen Sie Exact-, Parent- und Child-Suchen im festen Zeitraum und übernehmen Sie nur Expansionen, deren zusätzliche Treffer den Review-Aufwand rechtfertigen. Von [Tony Kim](https://zephior.com/de/authors/tony-kim). Veröffentlicht 2026-09-02; aktualisiert 2026-09-02. 10 Min. Lesezeit. ## Definition Eine Code-Expansion Policy legt fest, welche Ebenen um einen freigegebenen Seed Code überwacht werden. Sie behandelt Exact Code, ausgewählte Children, Parent und benachbarte Branches als getrennte Query Arms. Für jeden Arm hält sie Zielportal, Codesystem-Edition, Query Expression, Testfenster, zusätzliche brauchbare Treffer, False Positives, Exclusions, Review Cost und Entscheidung fest. Das Parent-, Child- und Exclusion-Table ist eine ausführbare Suchregel und kein Katalog aller theoretisch möglichen Kategorien. ## Problem Ein exakter Code verpasst Käufer, die auf einer breiteren oder angrenzenden Ebene publizieren. Der Parent kann solche Notices zurückbringen, zusammen mit einer viel grösseren Menge fremder Arbeit. Alle Children auszuwählen wirkt präzise, lässt aber Notices aus, die nur mit dem Parent erfasst wurden. Dazu kommt die Portalmechanik: Eine Suche kann Descendants automatisch einschliessen, eine andere nur den eingegebenen Wert matchen. Viele Teams überwachen deshalb eine ganze Division. Nach einigen Tagen ignorieren sie den Alert. Andere feiern einen ruhigen Alert, obwohl bekannte relevante Notices darin fehlen. ## Perspektive Leiten Sie die Suchbreite nicht allein aus dem Taxonomy Tree ab. Führen Sie Exact-, Child- und Parent-Suchen im tatsächlichen Zielportal getrennt und unter denselben Datums-, Orts- und Notice-Bedingungen aus. Nutzen Sie eine schriftliche Relevanzregel und ein Set bekannter Notices als Challenge. Precision lässt sich direkt am geprüften Result Set messen. Nennen Sie Recall nur Benchmark Coverage, solange nicht alle relevanten Notices im Corpus bekannt sind. Ein breiter Arm wird aufgenommen, wenn seine einzigartigen brauchbaren Treffer den zusätzlichen Review rechtfertigen. Laute Parents erhalten Subject Terms, Buyer Filters oder begründete Exclusions. Ein Agent darf suchen, deduplizieren und rechnen; Qualification bleibt ausserhalb dieser Entscheidung. ## Jede Codeebene unter denselben Bedingungen testen Starten Sie erst, wenn der Seed Code für das Angebot vertretbar ausgewählt wurde. Code Mapping fragt, welche Kategorie den Beschaffungsgegenstand beschreibt. Expansion fragt, wie viel benachbarte Hierarchie eine Suche beobachten soll. Fixieren Sie Zielportal und Interface oder API Version, Codesystem-Edition, abgeschlossenes Publication Window, Geography und Notice Scope. Schreiben Sie eine Relevanzregel, die ein zweiter Reviewer anwenden kann. Ein Resultat kann zum Beispiel relevant sein, wenn sein dominanter Scope eine lieferbare Implementierung oder einen Betrieb verlangt, das Land bedient wird und keine sofort sichtbare Mussbedingung den Auftrag unmöglich macht. Der Code Match allein reicht nie. Bauen Sie ein kleines Reference Set aus bereits geprüften offiziellen Notices. Es enthält passende und unpassende Records sowie schwierige Fälle: eine relevante Notice nur mit Parent Code, einen unpassenden Exact Match, einen Mixed Contract und einen über Text statt Code gefundenen Treffer. Das Set ist kein vollständiges Abbild des Marktes. Es soll klare Blind Spots entlarven. Ist die gesamte Zahl relevanter Notices unbekannt, berichten Sie Known-item Coverage oder Benchmark Recall, niemals scheinbar absoluten Recall. Precision bezieht sich auf die tatsächlich geprüften Resultate. Ein ungeprüfter Tail wird separat ausgewiesen und nicht still als irrelevant gezählt. **Record für den Retrieval Test** | Feld | Zu erfassen | Nutzen | | --- | --- | --- | | Seed | System, Edition, Code und Official Label | Hält die Auswahl konstant | | Surface | Portal, Endpoint oder Interface Version | Macht Verhalten reproduzierbar | | Window | Publication Dates und Geography | Macht Arms vergleichbar | | Scope | Notice Types und Status | Verhindert gemischte Nenner | | Relevanz | Schriftliche Include- und Reject-Regel | Begrenzt Judgement Drift | | Challenge Set | Offizielle Notice IDs mit Urteil | Prüft bekannte Misses | | Budget | Records oder Minuten je Zyklus | Definiert nutzbare Breite | ## Exact-, Child- und Parent-Suchen getrennt ausführen Zeichnen Sie nur den lokalen Branch: Parent des Seed, seine Children und durch echte Käuferpraxis belegte Siblings. Eine Hierarchie ist keine Einladung, den ganzen Baum zu überwachen. CPV standardisiert den Gegenstand europäischer öffentlicher Aufträge. UNSPSC erlaubt ausdrücklich, in seiner fünfstufigen Hierarchie für mehr oder weniger analytisches Detail nach oben oder unten zu gehen. Diese Eigenschaften erklären die Vokabulare, aber nicht jedes Suchformular. Die TED Developer Documentation behandelt CPV ebenfalls hierarchisch; ihr SPARQL-Beispiel nutzt Code Prefix und SKOS-broader Beziehungen für Subtypes. Das Zielportal kann eine andere Query Contract besitzen. Testen und speichern Sie sein beobachtetes Verhalten. Bauen Sie einen Arm für Exact Seed, einen für die freizugebenden Children, einen für Parent und eigene Arms für belegte Siblings. Ergänzen Sie eine Text-only Control aus dem Angebotsvokabular. Für einen lauten Code kommen Combined Variants mit einem unterscheidenden Subject Term hinzu. Deduplizieren Sie vor jedem Vergleich über die offizielle Notice Identity. Erscheint dieselbe Notice in Parent, Child und Text Query, ist sie eine Opportunity und nicht drei Erfolge. Die Find-Provenienz bleibt erhalten, weil sie zeigt, ob die Expansion einzigartigen Nutzen gebracht hat. - Descendant-Verhalten nie aus dem visuellen Code Picker ableiten. - Literal Query, Timestamp und Result Count je Arm speichern. - Main und Supplemental Classification getrennt halten, sofern verfügbar. - Vor dem Scoring über stabile offizielle Notice Identity deduplizieren. - Eine Text-only Control für falsch oder anders klassifizierte Notices behalten. ## Expansion nach marginalem Nutzen statt Volumen freigeben Precision ist der Anteil relevanter Records an allen geprüften zurückgegebenen Records. Recall ist der Anteil aller relevanten Records, die gefunden wurden. Der zweite Nenner ist in einem offenen Tender Corpus selten vollständig bekannt. Verwenden Sie darum ein datiertes Reference Set und benennen Sie die Einschränkung. Die wichtigste Zahl ist marginal: Wie viele relevante Notices ergänzt dieser Arm, die alle bisher freigegebenen Arms verpasst haben? Stellen Sie daneben einzigartige False Positives und Review-Minuten. Ein Parent mit sechs brauchbaren und 240 fremden Notices kann operativ schlechter sein als ein Child mit vier brauchbaren und zwölf fremden. Der Wert eines Miss und die echte Teamkapazität entscheiden, nicht eine universelle Quote. Vor dem Reject eines breiten Parent testen Sie ein oder zwei erklärbare Constraints. Ein Subject Term grenzt den beabsichtigten Service ein. Ein Buyer- oder Sector Filter kann eine Branch Boundary ziehen. Eine Exclusion entfernt ein ständig wiederkehrendes Fremdthema. Prüfen Sie negative Regeln an Mixed Contracts: Wer Hardware ausschliesst, kann einen gültigen Systems-Integration Contract mit Geräten verstecken. Verengen Sie dann die Regel oder überlassen Sie den Fall Human Triage. Stoppen Sie die Optimierung, sobald ein weiterer Filter relevante Ergänzungen entfernt, das Review Budget sprengt oder ein Feld benötigt, das die Quelle nicht verlässlich liefert. **Parent-, Child- und Exclusion-Entscheid** | Arm | Zu bewahrende Evidenz | Typischer Entscheid | | --- | --- | --- | | Exact Seed | Relevant, irrelevant und Known Misses | Als Baseline behalten | | Selected Children | Unique useful Notices und Parent-only Misses | Benannte Children behalten | | Parent allein | Marginal Value und Review Cost | Reject oder Condition | | Parent plus Phrase | Wiedergewonnener Nutzen nach Constraint | Mit Paired Filter behalten | | Belegter Sibling | Buyer Evidence und Unique Value | Test oder Reject | | Exclusion | Entfernte Noise und relevante Verluste | Nur sicher automatisieren | | Text Control | Relevante Records ausserhalb der Code Arms | Parallel bewahren | ## Eine ausführbare und anfechtbare Search Policy publizieren Überführen Sie das Decision Table in versionierte Instruktionen. Jeder freigegebene Arm nennt Codesystem und Edition, Hierarchy Path, Exact Query, Paired Terms, Exclusions, Portal, Geography, Notice Types, Test Window, Result Counts, Judgement Coverage, Marginal Additions, Owner und nächsten Review Trigger. Auch Rejected Arms bleiben sichtbar. Ohne ihren Grund wird ein späterer Analyst oder Agent den breiten Parent erneut einschalten und das Noise-Experiment wiederholen. Beobachtete Portal Facts müssen von internen Policy Choices getrennt bleiben. Ein Agent darf freigegebene Read-only Searches ausführen, IDs normalisieren und deduplizieren, Source URLs anhängen, die vereinbarten Werte rechnen und Drift melden. Er soll verzichten, wenn Portal Syntax wechselt, der Code verschwindet, eine Exclusion mit einer neuen relevanten Notice kollidiert oder ein grosser Result Tail ungeprüft ist. Sichere nächste Aktion ist die Rückgabe des betroffenen Arms mit Evidenz. Mehr Discovery erlaubt weder Qualification noch Outreach, Registration oder Submission. Die Policy ist gut, wenn ein Mensch jeden Branch versteht und neue Evidenz ihn ändern kann, ohne den Test neu zu erfinden. - Code Edition und ausführbare Query gemeinsam versionieren. - Observed Facts von Approval Decisions sichtbar trennen. - Drift Triggers für Volumen, Precision, Misses und Portalverhalten setzen. - Review bei veränderten Exclusions oder Hierarchy Semantics verlangen. - Discovery Output strikt von Bid Qualification trennen. ## Nützliche Ergebnisse - Jede Expansion startet mit einem freigegebenen Seed Code und einem Zielportal. - Exact, Parent, Children und Neighbors werden als getrennte Query Arms gemessen. - Testfenster, Geography, Notice Types und Relevanzregel bleiben konstant. - Unique Relevant Additions werden von doppeltem Alert Volume getrennt. - Precision, Benchmark Coverage und Review Effort erscheinen als eigene Grössen. - Breite Codes besitzen Paired Filters und dokumentierte Ausschlüsse. - Mensch oder Agent kann jeden Branch-Entscheid reproduzieren und anfechten. ## Ablauf 1. **Testbedingungen einfrieren.** Benennen Sie Portal, Edition, Seed Code, Datumsfenster, Geography, Notice Types, Relevanzregel und das Maximum an Records oder Minuten pro Review-Zyklus. 2. **Unabhängige Query Arms bauen.** Führen Sie Exact Code, ausgewählte Children, Parent und belegte Neighbors separat aus. Erfassen Sie die wörtliche Query und jede automatische Hierarchie-Expansion. 3. **Resultate urteilen und deduplizieren.** Prüfen Sie Notices gegen dieselbe Regel, bewahren Sie offizielle IDs und trennen Sie einzigartige Ergänzungen von Treffern anderer Arms. 4. **Marginale Coverage bepreisen.** Vergleichen Sie je Arm zusätzliche relevante Notices mit False Positives und erwarteten Review-Minuten. Testen Sie Constraints vor Freigabe eines lauten Parent. 5. **Begrenzte Policy publizieren.** Approve, Condition oder Reject für jeden Branch, ergänzt um Exclusions, Stop Rules, Owner, Review Date und Evidenz zum Wiederöffnen. ## Wichtige Entscheidungen - Interpretiert die Zielsuche einen Parent exakt oder schliesst sie Descendants ein? - Welche bekannten relevanten Notices findet und verpasst der Seed Code? - Ergänzen Children Resultate ausserhalb des Exact Arms? - Liefert der Parent passende Arbeit oder vor allem angrenzende Kategorien? - Welcher Text-, Buyer-, Orts- oder Notice-Type-Filter rettet einen lauten Branch? - Wie viel menschliche Review-Zeit darf der regelmässige Alert verbrauchen? - Welche Exclusion bleibt sicher, wenn ein Vertrag mehrere Leistungsarten mischt? - Welche neue Evidenz löst die nächste Expansion Review aus? ## Risiken - Das Portal kann eine Ebene bereits expandieren und versteckte Duplikate erzeugen. - Ein nur aus früheren Wins gebauter Benchmark blendet neue, passende Arbeit aus. - Ein Parent wirkt wegen hoher Result Count wertvoll statt wegen brauchbarer Treffer. - Eine Child-only-Suche verpasst Notices, die nur auf Parent Level klassifiziert sind. - Ein negatives Keyword entfernt möglicherweise einen legitimen Mixed Contract. - Precision vor Notice-level Deduplication belohnt wiederholte Resultate. - Eine Taxonomy- oder Portaländerung macht die gespeicherte Regel falsch. ## Kennzahlen - geprüfte und relevante Resultate je Query Arm - Precision nach Notice-level Deduplication - gefundene bekannte relevante Notices je Arm - Unique Relevant Additions von Parent, Children und Neighbors - Unique False Positives jeder Expansion - geschätzte Reviewer-Minuten je neuem brauchbarem Treffer - wöchentliches Alert Volume gegen freigegebenes Review Budget - nach System- oder Portaländerung revalidierte Entscheidungen ## Häufige Fragen ### Soll ein Tender Alert immer den Parent Code enthalten? Nein. Testen Sie ihn als eigenen Arm. Behalten Sie ihn nur, wenn seine zusätzlichen relevanten Notices die False Positives und Review Cost rechtfertigen, oft mit Paired Filter. ### Sucht ein Parent automatisch in allen Child Codes? Nicht in jedem Portal oder Interface. Prüfen Sie das Verhalten praktisch, speichern Sie die Query und testen Sie bekannte Child-coded Notices. ### Kann eine offene Tendersuche echten Recall messen? Meist nicht, weil die Gesamtmenge relevanter Notices unbekannt ist. Berichten Sie Coverage gegen ein datiertes, offengelegtes Reference Set und nennen Sie die Grenze. ### Kann ein Agent die Expansion automatisch optimieren? Er kann begrenzte Tests ausführen und Änderungen vorschlagen. Neue Branches oder Exclusions brauchen Review, weil Relevanz, Missed Value und Kapazität Business Judgements sind. ## Primärquellen - [Gemeinsames Vokabular für öffentliche Aufträge](https://single-market-economy.ec.europa.eu/single-market/public-procurement/digital-procurement/common-procurement-vocabulary_de), Europäische Kommission - [TED Search API](https://docs.ted.europa.eu/api/latest/search.html), Publications Office of the European Union - [TED Beispiele für Procurement-object Queries](https://docs.ted.europa.eu/ODS/latest/snippets/index.html), Publications Office of the European Union - [United Nations Standard Products and Services Code](https://www.undp.org/unspsc), United Nations Development Programme - [Evaluation of unranked retrieval sets](https://nlp.stanford.edu/IR-book/html/htmledition/evaluation-of-unranked-retrieval-sets-1.html), Stanford University ## Weiterführende Artikel - [CPV-Code: So funktioniert die Tender-Klassifikation](https://zephior.com/de/glossary/cpv-code) - [Welche Beschaffungscodes passen zu Ihrem Angebot?](https://zephior.com/de/insights/map-an-offer-to-procurement-classification-codes) - [Ausschreibungsmonitoring: von Treffern zu qualifizierten Chancen](https://zephior.com/de/insights/tender-monitoring-strategy) - [Ausschreibungen trotz ungewohnter Auftraggeberbegriffe finden](https://zephior.com/de/insights/search-when-buyers-use-unfamiliar-vocabulary)