Additions:
1. Seitens der Produktsortierung und der Qualität der Suchergebnisse liefert der Affilinator nur das, was auch affilinet liefert, die effektiv auch nur das zeigen und finden können, was die jeweiligen Shopbetreiber sauber pflegen. Stellt ein Shop also schlechte, fehlerhafte oder unzureichende Daten zur Verfügung, dann sind sie einfach nicht da bzw. falsch und können dementsprechend auch nicht richtig angezeigt werden.
In so einem Fall versuchen wir und aktive Nutzer eigentlich immer sofort den jeweiligen Partnerprogrammbetreiber zu informieren, aber bei aktuell über 6 Millionen (!) Datensätzen müssen eventuelle fehler auch erst einmal gefunden werden.
2. Auch wenn der Affilinator unserer Meinung nach aktuell Konkurrenzlos ist, ist es noch immer ein Skript, dass im Wesentlichen nur Daten von affilinet (und anderen Datenquellen und Schnittstellen) darstellt und kann daher immer nur so gut sein wie die Datenquelle selbst. Warum z.B. Funktionen der großen Preisvergleicher wie kelkoo usw. nicht gehen haben ihre Ursache einfach nur darin, dass diese Dienste eine eigene Datenbank pflegen, auf gigantischen Servern laufen UND das deren Applikationen ein vielfaches (!) des Affilinator Preises kosten würden (kelkoo konnte man glaube ich mal für über 400 (!) Millionen Euros kaufen...).
Deletions:
1. Seitens der Produktsortierung und der Qualität der Suchergebnisse liefert der Affilinator nur das, was auch affilinet liefert, die effektiv auch nur das zeigen und finden können, was die jeweiligen Shopbetreiber sauber pflegen. Stellt ein Shop also schlechte, fehlerhafte oder unzureichende Daten zur Verfügung, dann sind sie einfach nicht da und können dementsprechend auch nicht richtig angezeigt werden.
2. Auch wenn der Affilinator unserer Meinung nach aktuell Konkurrenzlos ist, ist es noch immer ein Skript, dass im Wesentlichen nur Daten von affilinet (und anderen Datenquellen und Schnittstellen) darstellt und kann daher immer nur so gut sein wie die Datenquelle selbst. Warum z.B. Funktionen der großen Preisvergleicher wie kelkoo usw. nicht gehen haben ihre Ursache einfach nur darin, dass diese Dienste eine eigene Datenbank pflegen, auf gigantischen Servern laufen UND das deren Applikationen ein vielfaches (!) des Affilinator Preises kosten würden (ich denke Tausendfach ist noch zu wenig...).
Additions:
- **searchProductsInCategories**: auch hier fehlt uns im Moment die Idee diesen Call besucherfreundlich umzusetzen - wie könnte ein Besucher gleichzeitig in mehreren Kategorien suchen, sprich wie und warum wählt er diese aus ? Ich denke das macht nur Sinn, wenn man als Webmaster bereits ganz genau weiß wo der Besucher suchen soll und die Seite ganz stark individualisiert ist (Suche nur in Rotwein und Rose, aber nicht in Weißwein...) , das ist denkbar, aber wie bauen wir so etwas in einem konfigurierbarem Skript ein ?
Deletions:
- **searchProductsInCategories**: auch hier fehlt uns im Moment die Idee diesen Call besucherfreundlich umzusetzen - wie könnte ein Besucher gleichzeitig in mehreren Kategorien suchen, sprich wie und warum wählt er diese aus ? Ich denke das macht nur Sinn, wenn man als Webmaster bereits ganz genau weiß wo der Besucher suchen soll und die Seite ganz stark individualisiert ist (Suche nur in Rotwein und Rose, aber nicht in Weißwein..:) , das ist denkbar, aber wie bauen wir so etwas in einem konfigurierbarem Skript ein ?
Additions:
- **getProducts**: hier fehlt uns ebenfalls die richtige Idee des Erfinders. Mehrere (einzelne) Produkte werden ggf. im Affilinator über die eindeutige Suche oder gecachte Daten dargestellt. Um den Call sinnvoll nutzen zu können müsste man mindestens 2 Product IDs kennen und übergeben. Aus Besuchersicht bedeutet das, dass der Besucher 2 Produkte kennen müsste und sie dann evtl. vergleichen würde. Die Funktion ist von anderen Seiten bekannt, macht aber aus unserer Sicht auch erst richtig Sinn, wenn z.B. die Produkteigenschaften in den XML-Daten deutlicher unterschieden werden. Ein Warenkorb fällt auch sofort ein, aber es ist eben nicht möglich 2 Produkte gleichzeitig zu übergeben, schon gar nicht an unterschiedliche Shops. Eine andere Verwendung wäre die Anzeige der zuletzt gecachten / gesehenen Produkte, aber da diese sich ja bereits im Cache befinden haben wir auf einen weiteren Call verzichtet und greifen sie dort ab. Auch hier sind Vorschläge natürlich immer willkommen, rein technisch ist der Call eigentlich schnell umgesetzt.
Deletions:
- **getProducts**: hier fehlt uns ebenfalls die richtige Idee des Erfinders. Mehrere (einzelne) Produkte werden ggf. im Affilinator über die eindeutige Suche oder gecachte Daten dargestellt. Um den Call sinnvoll nutzen zu können müsste man mindestens 2 Product IDs kennen und übergeben. Aus Besuchersicht bedeutet das, dass der Besucher 2 Produkte kennen müsste und sie dann evtl. vergleichen würde. Die Funktion ist von anderen Seiten bekannt, macht aber aus unserer Sicht auch erst richtig Sinn, wenn z.B. die Produkteigenschaften in den XML-Daten deutlicher unterschieden werden. Ein Warenkorb fällt auch sofort ein, aber es ist eben nicht möglich 2 Produkte gleichzeitig zu übergeben, schon gar nicht an unterschiedliche Shops.
Eine andere Verwendung wäre die Anzeige der zuletzt gecachten / gesehenen Produkte, aber da diese sich ja bereits im Cache befinden haben wir auf einen weiteren Call verzichtet und greifen sie dort ab. Auch hier sind Vorschläge natürlich immer willkommen, rein technisch ist der Call eigentlich schnell umgesetzt.
Additions:
- **getProducts**: hier fehlt uns ebenfalls die richtige Idee des Erfinders. Mehrere (einzelne) Produkte werden ggf. im Affilinator über die eindeutige Suche oder gecachte Daten dargestellt. Um den Call sinnvoll nutzen zu können müsste man mindestens 2 Product IDs kennen und übergeben. Aus Besuchersicht bedeutet das, dass der Besucher 2 Produkte kennen müsste und sie dann evtl. vergleichen würde. Die Funktion ist von anderen Seiten bekannt, macht aber aus unserer Sicht auch erst richtig Sinn, wenn z.B. die Produkteigenschaften in den XML-Daten deutlicher unterschieden werden. Ein Warenkorb fällt auch sofort ein, aber es ist eben nicht möglich 2 Produkte gleichzeitig zu übergeben, schon gar nicht an unterschiedliche Shops.
Eine andere Verwendung wäre die Anzeige der zuletzt gecachten / gesehenen Produkte, aber da diese sich ja bereits im Cache befinden haben wir auf einen weiteren Call verzichtet und greifen sie dort ab. Auch hier sind Vorschläge natürlich immer willkommen, rein technisch ist der Call eigentlich schnell umgesetzt.
Deletions:
- **getProducts**: hier fehlt uns ebenfalls die richtige Idee des Erfinders. Mehrere (einzelne) Produkte werden ggf. im Affilinator über die eindeutige Suche oder gecachte Daten dargestellt. Um den Call sinnvoll nutzen zu können müsste man mindestens 2 Product IDs kennen und übergeben. Aus Besuchersicht bedeutet das, dass der Besucher 2 Produkte kennen müsste und sie dann evtl. vergleichen würde. Die Funktion ist von anderen Seiten bekannt, macht aber aus unserer Sicht auch erst richtig Sinn, wenn z.B. die Produkteigenschaften in den XML-Daten deutlicher unterschieden werden. Eine andere Verwendung wäre die Anzeige der zuletzt gecachten / gesehenen Produkte, aber da diese sich ja bereits im Cache befinden haben wir auf einen weiteren Call verzichtez´t und greifen sie dort ab. Auch hier sind Vorschläge natürlich immer willkommen, rein technisch ist der Call eigentlich schnell umgesetzt.
Additions:
Da wir selber aktive Affiliates sind haben wir versucht das beste aus den affilinet Webservices raus zu holen, wobei auch unsere Sichtweise nicht immer perfekt sein muss. Hegt jemand Zweifel sollte er also unsere Demo erst einmal testen und ggf. weitere Fragen im [[http://www.affilinator.de/forum/3_vor-dem-kauf/ Forum]] stellen.
1. Seitens der Produktsortierung und der Qualität der Suchergebnisse liefert der Affilinator nur das, was auch affilinet liefert, die effektiv auch nur das zeigen und finden können, was die jeweiligen Shopbetreiber sauber pflegen. Stellt ein Shop also schlechte, fehlerhafte oder unzureichende Daten zur Verfügung, dann sind sie einfach nicht da und können dementsprechend auch nicht richtig angezeigt werden.
2. Auch wenn der Affilinator unserer Meinung nach aktuell Konkurrenzlos ist, ist es noch immer ein Skript, dass im Wesentlichen nur Daten von affilinet (und anderen Datenquellen und Schnittstellen) darstellt und kann daher immer nur so gut sein wie die Datenquelle selbst. Warum z.B. Funktionen der großen Preisvergleicher wie kelkoo usw. nicht gehen haben ihre Ursache einfach nur darin, dass diese Dienste eine eigene Datenbank pflegen, auf gigantischen Servern laufen UND das deren Applikationen ein vielfaches (!) des Affilinator Preises kosten würden (ich denke Tausendfach ist noch zu wenig...).
Wer kelkoo will, muss eben auch wie kelkoo denken und zahlen.
Deletions:
Da wir selber aktive Affiliates sind haben wir versucht das beste aus den affilinet Webservices rauszuholen, wobei auch unsere Sichtweise nicht immer perfekt sein muss. Hegt jemand Zweifel sollte er also unsere Demo erst einmal testen und ggf. weitere Fragen im [[http://www.affilinator.de/forum/3_vor-dem-kauf/ Forum]] stellen.
1. Seitens der Produktsortierung und der Qualität der Suchergebnisse liefert der Affilinator nur das, was auch affilinet liefert, die effektiv auch nur das zeigen und finden können, was die jeweiligen Shopbetreiber sauber pflegen.
2. Auch wenn der Affilinator unserer Meinung nach aktuell Konkurrenzlos ist, ist es noch immer ein Skript, dass nur Daten von affilinet darstellt und kann daher immer nur so gut sein wie die Datenquelle. Warum z.B. Funktionen der großen Preisvergleicher wie kelkoo usw. nicht gehen haben ihre Ursache einfach nur darin, dass diese Dienste eine eigene Datenbank pflegen, auf gigantischen Servern laufen UND das deren Applikationen ein vielfaches (!) des Affilinator Preises kosten würden (ich denke Tausendfach ist noch zu wenig...).
Startseite
Forum
Affilinator kaufen
Dokumentation
Kontakt