Fajny tekst Kacper. Wdrożenie automatycznych zmian cen w oparciu o politykę to dość duży effort i może być bardzo duży opór zarówno z biznesu jak i z obszaru technicznego klienta. Wymaga grzebania jak piszesz w silniku e-commerce. Alternatywą jest wdrożenie np Delavo czy innego narzędzia do zarządzania kontekstem ceny. Ktoś musiałby podjąć decyzję o tym że w to idzie i zaangażować się ale na końcu prawdopodobnie miałby efekty znacznie mniej precyzyjne i gorsze niż z ww Delavo. Wobec tego moim zdaniem (mogę się mylić) bardzo ciekawe, dzięki za to ale nie jestem przekonany (samo udostępnianie COGS to będzie wyzwanie).
Drugi temat natomiast jest znacznie szybszy do wdrożenia i nie wymaga takiego effortu. Data transfery wykorzystujemy min w Data Octopus. We wrześniu prawdopodobnie przetestujemy metodę, zobaczymy jakie dane nam wpadają. Pomyślimy jaki raport ( jako kolejny) zbudować na ich postawie w naszym środowisku analitycznym oraz jak wpleść je do Master modelu danych o produktach, aby stworzyć nowe możliwości segmentacji produktów na tej podstawie. Tym sposobem możemy trochę zaadresować 1 case a effort będzie mniejszy bo np ceny w sklepie nie zmienimy ale wiedząc o tym, że np jest konkurencyjna możemy wzmocnić inwestycję w dany produkt automatycznie.
Wiesz co, jedynka wymaga głównie sensownego rozwiązania asynchroniczności przekazywania informacji, z kolei dwójka powiedziałbym, że wymaga większego zaangażowania, szczególnie finansowego - koszty scrappu “na dziko” są drogie, a przynajmniej w uwarunkowaniach w PL, gdzie typowy e-comm nie ma pieniędzy, sprzedawanie tego jest ciężkie (a DWH jest uważane jako drogie, do czego przyczynił się globalnie m.in. Snowflake).
Sam pomysł na wpis z kolei powstał trochę z życia i trochę dlatego, że koszty platform do obsługi takich rzeczy są bardzo drogie (i ubogie) i często nieadekwatne pod kątem potrzebnego czasu na utrzymwanie całości (mała ilość zmian z gatunku tych “nieoficjalnych”, wystandaryzowane API, jasny cykl zarządzania produktami).
Jasne, dzięki za sugestię - od następnego wpisu będę załączał widgety z możliwością skopiowania. Co należy też zaznaczyć, to te przykłady działają, ale są głównie poglądowe: wszędzie zamieszczam odniesienia do dokumentacji technicznych, toteż można wyklikać to samodzielnie.
Fajny tekst Kacper. Wdrożenie automatycznych zmian cen w oparciu o politykę to dość duży effort i może być bardzo duży opór zarówno z biznesu jak i z obszaru technicznego klienta. Wymaga grzebania jak piszesz w silniku e-commerce. Alternatywą jest wdrożenie np Delavo czy innego narzędzia do zarządzania kontekstem ceny. Ktoś musiałby podjąć decyzję o tym że w to idzie i zaangażować się ale na końcu prawdopodobnie miałby efekty znacznie mniej precyzyjne i gorsze niż z ww Delavo. Wobec tego moim zdaniem (mogę się mylić) bardzo ciekawe, dzięki za to ale nie jestem przekonany (samo udostępnianie COGS to będzie wyzwanie).
Drugi temat natomiast jest znacznie szybszy do wdrożenia i nie wymaga takiego effortu. Data transfery wykorzystujemy min w Data Octopus. We wrześniu prawdopodobnie przetestujemy metodę, zobaczymy jakie dane nam wpadają. Pomyślimy jaki raport ( jako kolejny) zbudować na ich postawie w naszym środowisku analitycznym oraz jak wpleść je do Master modelu danych o produktach, aby stworzyć nowe możliwości segmentacji produktów na tej podstawie. Tym sposobem możemy trochę zaadresować 1 case a effort będzie mniejszy bo np ceny w sklepie nie zmienimy ale wiedząc o tym, że np jest konkurencyjna możemy wzmocnić inwestycję w dany produkt automatycznie.
Dzięki ciekawy artykuł.
Wiesz co, jedynka wymaga głównie sensownego rozwiązania asynchroniczności przekazywania informacji, z kolei dwójka powiedziałbym, że wymaga większego zaangażowania, szczególnie finansowego - koszty scrappu “na dziko” są drogie, a przynajmniej w uwarunkowaniach w PL, gdzie typowy e-comm nie ma pieniędzy, sprzedawanie tego jest ciężkie (a DWH jest uważane jako drogie, do czego przyczynił się globalnie m.in. Snowflake).
Sam pomysł na wpis z kolei powstał trochę z życia i trochę dlatego, że koszty platform do obsługi takich rzeczy są bardzo drogie (i ubogie) i często nieadekwatne pod kątem potrzebnego czasu na utrzymwanie całości (mała ilość zmian z gatunku tych “nieoficjalnych”, wystandaryzowane API, jasny cykl zarządzania produktami).
Jakbyś dał radę wrzucać kod jako txt a nie jako grafika byłym wdzięczny :)
Jasne, dzięki za sugestię - od następnego wpisu będę załączał widgety z możliwością skopiowania. Co należy też zaznaczyć, to te przykłady działają, ale są głównie poglądowe: wszędzie zamieszczam odniesienia do dokumentacji technicznych, toteż można wyklikać to samodzielnie.