Bảng điểm DR hàng tháng: Thiết lập cho công cụ BI của bạn

Lựa chọn những gì một con số DR domain có thể trả lời

Domain DR thực chất là một phép đếm ẩn. Đơn giản. Nó tăng lên khi có nhiều trang web khác nhau liên kết đến một domain, và thang đo logarit khiến mỗi điểm mới khó đạt được hơn điểm trước. Hãy ghi nhớ câu này vào ghi chú biểu đồ.

Một tile tốt trả lời một câu hỏi về xu hướng cho mỗi nhóm domain: liệu chúng ta có đang thu hẹp khoảng cách với ba đối thủ, liệu các đối tác có đang phát triển, hay một chiến dịch có tạo ra tác động không. Một tile kém sẽ kết hợp lưu lượng truy cập hoặc doanh thu và mời gọi một câu chuyện nhân quả mà dữ liệu không thể chứng minh.

Hãy lưu trữ cả số lượng domain tham chiếu thô. Nếu điểm số thay đổi một điểm, bạn có thể xem đó là do 40 domain mới hay 4.000 domain mới, và điều đó cho bạn biết liệu có cần lo lắng hay không.

Bảng nên và không nên lưu trữ gì

Một bảng snapshot là bộ nhớ của bạn. Nó nên lưu trữ những gì bạn cần để giải thích một biểu đồ sau một năm, và không lưu trữ những gì có thể dẫn đến cách giải thích sai lầm. Hãy bắt đầu với tập hợp nhỏ nhất các cột trả lời câu hỏi về xu hướng. Chỉ thêm một cột khi một cuộc họp yêu cầu.

Một số cột xứng đáng có mặt ngay từ ngày đầu tiên. Ít hơn những gì bạn nghĩ. Domain, điểm số, số lượng domain tham chiếu, ngày kéo dữ liệu và tên nguồn bao phủ hầu hết các câu hỏi. Một cột lưu lượng truy cập có vẻ hữu ích, nhưng nó đến từ một nguồn khác và một ngày khác, nên nó thuộc về một bảng khác.

Loại bỏ bất kỳ dữ liệu nào bạn có thể tính toán lại từ các dữ liệu khác. Sự chênh lệch giữa các tháng là một phép trừ, nên hãy lưu trữ nó trong một view thay vì như một bản sao thứ tư của cùng một sự thật.

Hãy ghi danh sách các cột vào ghi chú biểu đồ. Một người đọc mở biểu đồ sau một năm nên thấy mỗi con số đến từ đâu và lần kéo dữ liệu nào đã điền vào nó.

Các khóa ngăn chặn hàng trùng lặp

Khóa chính trên domain và ngày kéo dữ liệu không chỉ ngăn chặn trùng lặp. Nó cũng cho bạn biết một hàng đến từ lần kéo dữ liệu nào, điều này quan trọng khi một lần chạy lại xảy ra sau khi hết thời gian chờ. Hai hàng cho cùng một domain trong một tháng là không thể xảy ra, và lược đồ nên phản ánh điều đó.

Các tên nguồn bạn có thể lọc

Hãy ghi nguồn dưới dạng nhãn cố định, chẳng hạn như rankwiser_bulk_dr, chứ không phải là một ghi chú văn bản tự do. Bộ lọc trên nhãn đó giữ điểm số này tách biệt với bất kỳ điểm số nào bạn tải lên sau này. Hãy giữ danh sách nhãn ngắn và ghi nó xuống bên cạnh bảng.

Các biện pháp bảo vệ nên thêm ngay từ ngày đầu tiên

Giữ một bảng thứ hai về các lần kéo dữ liệu bị lỗi. Một hàng chứa trạng thái HTTP, thời gian và thân phản hồi tốt hơn một khoảng trống im lặng trong biểu đồ. Cảnh báo với mọi thứ ngoại trừ ok là true.

Ghim danh sách domain trong kiểm soát phiên bản. Các diff ngắn gọn sẽ hữu ích. Khi ai đó thêm một đối thủ, diff sẽ cho biết ai đã thêm nó và khi nào, và biểu đồ sẽ có ghi chú. Nếu không, đường biểu diễn cho đối thủ đó xuất hiện từ hư không và mọi người sẽ hỏi tại sao nó bắt đầu vào tháng 3.

Hãy lên kế hoạch cho sự thay đổi nguồn. Nếu sau này bạn thêm số liệu từ Ahrefs hoặc Moz, hãy cho chúng một giá trị nguồn riêng trong bảng, như đã thảo luận khi chúng tôi so sánh Ahrefs và Majestic.

Kiểm tra sức khỏe nhanh cho mỗi lần chạy hàng tháng

Trước khi tin tưởng một biểu đồ, hãy kiểm tra công việc đã điền vào nó. Sau đó hãy nhìn vào biểu đồ. Một lần chạy khỏe mạnh trả về ok là true, một hàng cho mỗi domain bạn yêu cầu, và số dư giảm đi đúng số tiền dự kiến. Bất kỳ điều gì khác đều là lý do để đọc phản hồi, chứ không phải là vẽ đường biểu diễn bất chấp.

Đếm số hàng đã thay đổi. Nếu một tỷ lệ lớn đã dịch chuyển ba điểm trở lên, hãy kiểm tra danh sách domain trước khi đổ lỗi cho chỉ số. Một đợt di chuyển đột ngột thường có nghĩa là danh sách đã thay đổi, chứ không phải là web.

Số lượng hàng khớp với danh sách là mức tối thiểu. Số hàng ít hơn có nghĩa là một domain đã bị loại bỏ ở đâu đó giữa tệp và bảng. Hãy tìm nó trước lần chạy tiếp theo.

Một tháng phẳng cho bạn biết điều gì

Một tháng với hầu như không có thay đổi không phải là bằng chứng về sự ổn định. Chỉ số được làm mới khoảng một lần mỗi tháng, nên một hàng phẳng có thể đơn giản là chưa được cập nhật. Hãy đọc một tháng yên tĩnh cùng với ngày kéo dữ liệu của nó, và nhớ rằng biểu đồ vẫn tuân theo lịch trình.

Ai sẽ nhận cảnh báo

Một cảnh báo gửi đến hộp thư chung sẽ bị bỏ qua trong vòng một tháng. Hãy chỉ định một người cho công việc này và một người thứ hai cho những ngày người đó vắng mặt. Cảnh báo nên nêu rõ danh sách domain, trạng thái HTTP và thời gian, để người đọc không phải mở script để hành động.

Kiểm tra một thay đổi trước khi triển khai chính thức

Nếu bạn thay đổi danh sách hoặc lịch trình, hãy chạy cả phiên bản cũ và mới song song trong một chu kỳ. Các hàng khớp nhau cho thấy thay đổi không gây ra tác động phụ. Một sự khác biệt mà bạn không thể giải thích nên dừng việc triển khai, dù nó nhỏ đến đâu.

Ghi chú về tần suất và nhịp độ

Không có gì ở đây cần tốc độ. Một lần chạy hàng tháng chỉ là một vài lệnh gọi, ngay cả với các danh sách lớn, và mỗi phản hồi đến dưới dạng một tài liệu JSON duy nhất. Nếu bộ lập lịch của bạn thử lại khi có lỗi, hãy đảm bảo lệnh thử lại là idempotent, điều mà khóa chính trên domain và ngày kéo dữ liệu đã mang lại cho bạn.

Hãy kháng cự lại urge chạy công việc hàng ngày chỉ vì nó rẻ. Đừng làm vậy. Chỉ số của chúng tôi được làm mới khoảng một lần mỗi tháng. Các lần kéo dữ liệu hàng ngày sẽ trả về cùng các hàng trong nhiều tuần, và biểu đồ của bạn sẽ đầy các đường phẳng trông giống như sự ổn định nhưng thực chất chỉ phản ánh lịch trình thu thập dữ liệu. Đọc các công thức thay thế Majestic cho các lần kéo dữ liệu khác đáng lên lịch, chẳng hạn như anchor text và intersections.

Sở hữu công việc sau khi ra mắt

Một công việc hàng tháng tồn tại lâu hơn người đã xây dựng nó. Sáu tháng sau, một người mới mở lệnh cron và tự hỏi tại sao danh sách lại nằm trong một tệp. Hãy viết một ghi chú ngắn. Đặt nó ở đầu script với mục đích, lịch trình và chi phí credit. Ghi chú đó rẻ hơn một cuộc họp về nó.

Xem xét danh sách domain mỗi quý. Loại bỏ những gì không còn quan trọng, và thêm các đối thủ mà quyết định thực sự phụ thuộc vào chúng. Mỗi thay đổi đều được đưa vào kiểm soát phiên bản với ngày tháng, để biểu đồ có thể hiển thị sự thay đổi thay vì ẩn nó đi.

Ngân sách cũng là một phần của việc xem xét. Một credit mỗi tháng. Chi phí vẫn rất nhỏ. Hãy kiểm tra số dư vào cùng ngày với biểu đồ, và ghi ngày nạp tiền tiếp theo vào cùng ghi chú đó.

Những câu hỏi mọi người hỏi về công việc hàng tháng

Bốn câu hỏi xuất hiện một khi công việc đã chạy được vài tháng. Mỗi câu trả lời là một quy tắc bạn có thể ghi vào ghi chú thiết lập.

Tại sao không kéo dữ liệu hàng ngày, vì các lệnh gọi rất rẻ?

Dữ liệu thay đổi theo lịch trình hàng tháng, nên một lần kéo dữ liệu hàng ngày sẽ lặp lại cùng các hàng trong nhiều tuần. Chi phí nhỏ, nhưng biểu đồ sẽ đầy các đường phẳng trông giống như sự ổn định. Một biểu đồ gửi đến ban giám đốc cũng cần ghi chú sổ tay báo cáo bảng điều khiển.

Nếu một đối thủ bị loại khỏi danh sách thì sao?

Hãy giữ lịch sử của nó, đánh dấu domain là đã bị loại và ngừng kéo dữ liệu cho nó. Một đường bị mất trông giống như một khoảng trống dữ liệu, nên hãy ghi lý do bên cạnh biểu đồ.

Tôi có thể chạy công việc vào một ngày khác không?

Có, nếu bạn chọn một ngày và giữ nó. Điểm mấu chốt là nhịp độ ổn định. Di chuyển ngày chạy vài ngày mỗi tháng sẽ khiến xu hướng khó đọc hơn.

Tôi phải làm gì với mã 402 ở giữa tháng?

Dừng công việc, nạp tiền từ trang tài khoản bằng USDT, và chạy lại chỉ lệnh gọi bị lỗi. Hãy giữ phản hồi bị lỗi trong nhật ký của bạn, để khoảng trống trong biểu đồ có lời giải thích bằng văn bản.